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Sobre o autor 


Meu nome é Jhones dos Santos Clementino, sou apaixonado por 
programação desde os 17 anos quando descobri que os softwares, 
games e sites eram desenvolvidos através de alguma linguagem de 
programação - essa descoberta mudou minha vida. Comecei a me 
interessar por esses assuntos cada vez mais e mais porque achava 
incrível uma sequência de código fazer algo tão útil e interessante 
como os jogos, por exemplo, isso é fascinante! =D 


Sou formado em Ciência da Computação pela Universidade Paulista 
- UNIP e trabalho com desenvolvimento de sistemas Web desde 
2009, quando ocorreu meu primeiro contato com o PHP. Desde 
aquela época fui me dedicando a aprender mais e mais com cursos 
online, tutoriais, livros e apostilas, e meu foco tem sido a Web 
porque são tecnologias que estão em constante evolução. Pretendo 
ampliar mais esse leque de plataformas e também dedicar-me ao 
mobile para projetos futuros que tenho em mente. 


Meu primeiro contato com o ecossistema Zend Framework 
(atualmente Laminas ) foi em 2013 quando ele já estava na versão 2. 
Entrei para área de TI de um banco, onde estavam fazendo um 
portal interno completamente em ZF2, foi então que encontrei a 
perfeita oportunidade para aprender a utilizar o ZF2 e gostei muito 
da sua forma explícita de definir a lógica. Há quem critique e há 
quem goste do ZF, eu particularmente gosto muito e posso dizer que 
é um dos meus frameworks preferidos, mas como um profissional 
não posso me deixar levar pelo favoritismo na escolha de um 
framework para trabalhar dentro de um ambiente corporativo, afinal, 
há muitas questões a serem consideradas. Também sou o autor do 
livro: PSRs - Boas Práticas de Programação em PHP, publicado 
exclusivamente pela editora Casa do Código. 


Quando possuo um tempo livre gosto de fazer alguma coisa que tire 
a minha atenção do mundo virtual por algum tempo, então gosto de 
sair, desenhar e até mesmo cantar (vamos deixar isso para uma 


outra hora, OK? Rs). Bom, meu amigo, esse é um resumão de 
quem sou eu. 


Prefacio 


No começo de 2020, a Zend anunciou que o projeto Zend 
Framework e seu ecossistema passaria por mudanças, dando 
adeus ao Zend Framework e boas-vindas ao projeto Laminas. 


Até então a Zend Technologies liderava o projeto do Zend 
Framework, que depois passou para a Rogue Wave Software. Com 
a transição o projeto está sendo liderado por um comitê técnico 
independente e em breve será regido por uma carta patente com a 
Linux Foundation. 


Vale ressaltar que o Zend Framework teve ampla adoção pelos 
profissionais de PHP, sendo a base de vários portais, e-commerces, 
sites, APIs, e muitos outros projetos. Com o fim do projeto Zend 
Framework e com o início do projeto Laminas, novos projetos 
surgirão e essa será como uma nova Era, a Era do projeto Laminas. 


É importante dizer que o Laminas e seus subprojetos são a 
continuação oficial do Zend Framework e continuará sendo de 
código aberto. Quando me refiro a subprojetos do Zend Framework, 
incluo o Zend Expressive e Apigility. 


Não se preocupe com as mudanças que o projeto teve. Ao longo do 
livro veremos quais foram as mudanças em nível de código e 
também teremos um capítulo que servirá de base para que você 
possa realizar a migração de seu código do Zend Framework para 
Laminas. 


Desde o lançamento do Zend Framework, a comunidade Zend tem 
crescido cada vez mais. Conforme a tecnologia e os anos foram 
avançando, tornou-se essencial a agilidade na entrega de novas 
aplicações. Contudo, a Zend ainda não possuía um framework 
enxuto para um desenvolvimento mais rápido de aplicações, focado 
em encontrar uma solução para o problema. Foi então que ela 
desenvolveu o que todos mais aguardavam, um microframework. 


Zend Expressive é um microframework criado pela Zend com o 
objetivo de atender desde as demandas mais simples para criação 
de aplicações de mínima escala a APIs e aplicações mais 
complexas de alta escala. 


IMPORTANTE 


Com a migração do código do Zend Framework para Laminas, o 
Zend Expressive passou a se chamar Mezzio. Daqui para frente 


o Zend Expressive será referenciado como Mezzio com exceção 
da menção aos conceitos históricos da Zend e seu ecossistema 
Zend Framework. 





Hoje em dia, o número de aplicações distribuídas está cada vez 
maior. Entende-se por aplicações distribuídas aquelas que 
funcionam de forma independente, ou seja, sem serem restritas a 
apenas um tipo de plataforma. O Mezzio vai nos ajudar a 
desenvolver uma API ou, como muitos chamam, Web Service, que 
funcionará de forma independente para que qualquer aplicação 
client possa fazer a comunicação de forma simples. 


Não se preocupe se no momento você não estiver entendendo 
muito bem, vamos falar muito sobre o Mezzio no decorrer deste 
livro, afinal ele é o protagonista desta obra. 


Este livro é indicado para os desenvolvedores que estão iniciando 
no mundo dos frameworks/microframeworks e também para os 
programadores mais experientes que já possuem um conhecimento 
mais avançado das tecnologias voltadas para a Web com o PHP. 


Para este livro, é necessário que o leitor tenha o conhecimento 
básico sobre PHP 7 e Programação Orientada a Objetos. Ambos 
são indispensáveis pois serão utilizados com frequência durante o 
desenvolvimento do nosso projeto. 


O projeto e os exemplos podem ser desenvolvidos utilizando: 


e S.O (Sistema Operacional): Linux Ubuntu 16.04 ou superior 
com suporte a PHP 7 / Windows 7 ou superior / MacOS com 
suporte a PHP 7; 

e Servidor: Apache2 ou Nginx; 

e Linguagem de programação: PHP 7.4 ou superior, 

e IDE: PHPStorm (Você pode utilizar qualquer outra IDE de sua 
preferência como: Eclipse, Netbeans, Sublime, Notepad++, 
Visual Studio Code entre outras); 

e Client HTTP para fazer as requisições da API: Postman ou 
outro client de sua preferência como: Advanced REST client, 
SOAP UI, entre outros; 

e Gerenciador de dependências: Composer na versão 1.7.0 ou 
superior. 


Os exemplos estão no repositório do GitHub: 
https://github.com/jhones/projeto-mezzio/. 


Caso o leitor possua dúvidas, críticas, sugestões ou correções, 
poderá entrar em contato através de um dos canais: 


e E-mail: jhones.developer@gmail.com 
e LinkedIn: https://www.linkedin.com/in/jhones-dos-santos- 
clementino-91a90256/ 


No decorrer deste livro, vamos abordar diversos temas envolvendo 
APIs, microsserviços e o microframework Mezzio, que foi lançado 
antes do Zend Framework 3 (atualmente Laminas MVC). Vamos 
abordar também como fazer a integração com o ORM Doctrine, 
falaremos de middlewares e muito mais. Por fim, vamos desenvolver 
uma API bem simples com o Mezzio e PHP 7 em que vamos 
realizar um CRUD de tipos de usuários, usuários e de mensagens. 
Nós vamos aplicar alguns dos componentes do Laminas para que o 
conhecimento adquirido seja fixado da melhor maneira possível. Se 
você está preparado para iniciar nossa jornada rumo ao mundo dos 
microframeworks e APIs então siga em frente aos próximos 
capítulos. Bom estudo! 


CAPITULO 1 
Introdução 


Hoje em dia, existem diversos frameworks dos mais variados tipos e 
complexidade. Com o surgimento de frameworks full stack, o 
trabalho dos desenvolvedores se tornou algo mais simples e eficaz, 
afinal esses frameworks trazem consigo um grande conjunto de 
bibliotecas que visam facilitar as tarefas do nosso dia a dia. 


Um framework full stack é um conjunto de componentes, bibliotecas 
e conceitos que seguem uma estrutura bem-definida que facilita a 
vida do desenvolvedor durante o desenvolvimento de um projeto. Já 
um microframework também é um conjunto de componentes, 
bibliotecas e conceitos, porém com uma estrutura minimalista capaz 
de criar aplicações de mínima escala, APIs, microsservicos, entre 
outras. No capítulo 3 você encontrará mais detalhes de cada tipo, 
exemplos, vantagens e desvantagens e quando usar framework full 
stack ou microframework, não se preocupe. 


Uma das grandes vantagens do framework full stack é a quantidade 
de bibliotecas fornecidas, dentre as quais podemos citar: validações, 
conexões com banco de dados, filtros, forms, autenticação, 
paginação. Mas Jhones, só existe vantagem em utilizar framework 
full stack? A resposta, meu amigo, é "não"! 


Tudo o que conhecemos hoje possui vantagens e desvantagens. 
Uma das grandes desvantagens desse tipo de framework é 
exatamente a quantidade de bibliotecas que são instaladas com o 
core do framework, pois nem tudo o que será instalado realmente 
será utilizado pelo desenvolvedor. 


Um bom exemplo de um framework desse tipo era o próprio Zend 
Framework 1 e 2. Quando fazíamos a instalação do ZF, todo o 
framework era instalado, ou seja, todas as bibliotecas eram 
instaladas sem necessidade junto com o framework. Isso acabava 


afetando a performance do sistema, por se tornar muito pesado com 
todas as bibliotecas instaladas. Para entender melhor, imagine o 
seguinte cenario: vocé acessa um site que carrega inumeras 
imagens de diversos tamanhos junto com o carregamento inicial da 
pagina; nao demora muito para vocé notar que a pagina esta lenta. 
Por que isso acontece”? A resposta é bem simples, o site carregou 
todas as imagens sem necessidade. Em vez de carregar apenas 
algumas imagens e colocá-las no cache, o site carrega todas sem 
nenhum tipo de tratamento. O exemplo citado parece absurdo, mas 
é exatamente o que acontece com o Zend Framework. Ao 
baixarmos e instalarmos ele virá com todas as bibliotecas e, 
consequentemente, afetará a performance do sistema. 


Felizmente quando a Zend desenvolveu o ZF3 (atualmente o projeto 
Laminas mvc ), foram desenvolvidas grandes melhorias, entre as quais 
podemos citar: a separação dos componentes do core do 
framework, ou seja, você instala somente o que realmente for utilizar 
em sua aplicação, diferentemente do seu antecessor. O Laminas 
MVC está mais robusto: se antes tínhamos todo o framework 
instalado com todos os seus componentes agora o foco foi na 
reusabilidade, interoperabilidade e performance. Ao baixá-lo, só os 
principais componentes são instalados junto com o framework a fim 
de assegurar sua correta execução e funcionamento como: laminas- 
mvc , laminas-eventmanager , laminas-modulemanager , laminas- 
servicemanager , laminas-router , entre outros. Além disso, ele possui 
suporte e compatibilidade para o desenvolvimento utilizando o PHP 
7. 


Outro ponto bem importante que vale a pena ressaltar é quanto á 
performance. O framework executa 4 vezes mais rápido do que o 
seu antecessor, Zend Framework 2. Vale ressaltar também que ele 
nao possuia um microframework para a criacáo de APIs ou 
aplicações de mínima escala, e a fim de resolver esse problema a 
Zend criou O Zend Expressive (atualmente chamado de mezzio ). Com 
esse nosso camarada podemos facilmente criar APIs seguindo os 
conceitos da PSR-7 e PSR-15, bem como fazer a integracáo de 


outros componentes tanto do Laminas quanto bibliotecas de 
terceiros. Por exemplo, se vocé nao gosta ou nao esta habituado a 
trabalhar com o modelo de rotas Laminas Router, não tem 
problema, vocé pode usar o Aura Router ou Fast Route. Tudo bem, 
legal essa parte, mas é só isso que ele pode oferecer? A resposta 
para essa pergunta, meu caro amigo, também é "nao"! 


O Mezzio está muito mais além do que podemos imaginar e 
conheceremos a fundo mais desse incrível microframework nos 
próximos capítulos. Para entendermos um pouco sobre o conceito 
de microframeworks, precisamos entender o motivo que levou ao 
seu surgimento. 


Por que usar microframeworks 


Com o passar dos anos, a necessidade por serviços cada vez mais 
ágeis foi crescendo de tal forma que os frameworks precisavam 
atender a essa demanda de forma mais rápida e eficaz. Assim, 
pouco a pouco, foram surgindo sistemas baseados em serviços ou, 
como chamamos, APIs (Application Programming Interface) e, 
consequentemente, novos frameworks menos engessados com o 
intuito de facilitar a criação de APIs: os famosos microframeworks. 


Muitas empresas e comunidades mantenedoras de seus 
frameworks começaram a acompanhar a nova evolução da Era das 
APIs, logo, foram surgindo diversos microframeworks como: Slim, 
Silex (já descontinuado), Lumen, Zend Expressive (atualmente 
Mezzio), entre outros tantos existentes. Apartir desse ponto, 
referenciarei o Zend Expressive já com o seu novo nome: Mezzio. 
Você pode estar se perguntando: É simples trabalhar com esses 
microframeworks? Como posso conhecer um pouco melhor cada 
um deles? A resposta está logo a seguir. Veja uma pequena lista 
das características de cada um dos microframeworks citados 


anteriormente para ver para que serve cada um deles e no que eles 
podem ajuda-lo: 


e Mezzio (antigo Zend Expressive) - é um microframework para 
criação de APIs, aplicações de mínima escala e microsserviços, 
além disso, possui compatibilidade com o PHP 7 e tem uma 
excelente performance. 

e Slim - é um microframework que nos ajuda a desenvolver APIs 
de maneira muito rápida e fácil. No mundo das APIs em PHP, é 
um microframework bastante conhecido. 

e Silex (já descontinuado) - é um microframework para criação 
de APIs e foi desenvolvido por Fabien Potencier, mesmo criador 
do Symfony, logo o Silex é baseado no próprio Symfony e 
possui uma boa performance. 

e Lumen - é um microframework baseado em Laravel para a 
construção de APIs e sua comunidade tem crescido muito 
devido à facilidade em sua utilização e a grande quantidade de 
pacotes disponíveis. A comunidade é bem ativa. 


Vale ressaltar que a escolha de um framework ou microframework 
vai muito além de qualidades técnicas, complexidade e 
performance: depende muito do projeto que será desenvolvido e até 
mesmo do gosto da pessoa. Eu, particularmente, prefiro as coisas 
mais explícitas mesmo que seja um pouco mais trabalhoso; mesmo 
assim, a escolha sempre dependerá do projeto a ser desenvolvido 
e, principalmente, do prazo a ser cumprido. 


Muitos desenvolvedores que migram constantemente entre 
frameworks full stack e microframeworks, seja por aventura e 
conhecimento, seja devido ao dia a dia no trabalho, notarão que as 
coisas no Laminas MVC / Mezzio são mais explícitas e devem ser 
definidas. Ou seja: vai criar uma action? Tem que defini-la no 
arquivo de configuração. Vai criar um serviço? Tem que defini-lo no 
arquivo de configuração. E será assim praticamente com boa parte 
do que você for criar no framework. 


Mas você pode estar se perguntando: qual a diferença entre o 
Laminas MVC e o Mezzio? A diferença é que o Laminas MVC é um 
framework full stack com uma estrutura mais complexa para o 
desenvolvimento de aplicações mais robustas e com mais recursos. 
Já o Mezzio é um microframework para o desenvolvimento, desde 
APIs e aplicações mais simples, até aplicações mais complexas. 
São notáveis os esforços que a Zend teve para tornar o framework e 
o microframework ferramentas de desenvolvimento cada vez 
melhores antes mesmo de dar adeus ao ecossistema Zend 
Framework e boas-vindas ao ecossistema Laminas. Não podíamos 
iniciar este livro sem apresentar a essência do conhecimento por 
trás de toda essa tecnologia. 


Neste livro veremos o microframework que veio para agregar 
valores e conhecimentos principalmente no mundo das APIs. Nos 
próximos capítulos, veremos muito do Mezzio e do que ele é capaz 
de nos proporcionar para tornar o desenvolvimento de APIs e 
microsserviços mais ágil. 


CAPITULO 2 
Migrando para o Laminas 


Se vocé possui algum projeto desenvolvido em Zend Framework 3 
ou em Zend Expressive ou se vocé ja comprou a versao anterior 
deste livro (Zend Expressive e PHP7: Uma união poderosa para 
criação de APIs) e desenvolveu o projeto junto com o livro, então 
você poderá realizar a migração do seu código para o Laminas. Não 
se preocupe, realizar essa migração não é complicada e você 
aprenderá isso nas próximas seções deste capítulo. 


2.1 Preparação para realizar a migração 


Primeiramente, precisamos verificar a versão do nosso composer 
que está instalado. Execute o código a seguir na raiz do projeto em 
seu terminal: 


composer --version 


Se a sua versão do composer for inferior a 1.7.0 então será 
necessário você atualizar o seu composer. Para realizar essa 
atualização, em seu terminal na raiz do seu projeto, execute o 
comando a seguir: 


composer self-update 


Esse comando atualizará o seu composer. Após sua execução, você 
deve obter uma saída semelhante a exibida na imagem a seguir: 


$ composer se 


Updating to version (stable channel). 


Downloading ( | 
Use to return to version 





Figura 2.1: Atualizando a Versao do Composer 


Se a saida for semelhante a da imagem anterior, entao vocé esta 
pronto para prosseguir, caso contrário, revise os passos e tente 
novamente. 


IMPORTANTE: VERIFIQUE SE O SEU C DIGO ESTÁ VERSIONADO 
A ferramenta de migração realiza alterações no código-fonte, 
atualizando templates, alterando O composer.json , removendo o 


composer . lock , entre outras alterações. O versionamento do 
código permite que você restaure os arquivos originais do seu 
projeto em caso de erros. 





Instalando o pacote laminas-migration em modo global 
(recomendado) 


Para instalarmos o pacote laminas-migration , Você deverá executar O 
comando a seguir em seu terminal. Ele executará o composer de 
forma global instalando o pacote laminas-migration . 


sudo composer global require laminas/laminas-migration 


Após a execução do comando anterior você deverá ver uma saída 
semelhante à exibida na imagem a seguir: 





Do not run Composer as root/super user! See https://getcomposer.org/root for details 
Using version 





- Installing (1.5.1): Downloading (100%) 

- Installing .0.0): Downloading (100%) 

- Installing (v2.0.1): Downloading (100* 

- Installing (v1.13.1): Downloading (16 

- Installing (v1.13.1): Downloading (100%) 
- Installing (v5.0.4): Downloading (100%) 


- Installing (1.0.1): Loading from cache 
- Installing (1.0.2): Loading from cache 
symfony/service-contracts suggests installing symfony/service-implementation 
symfony/console suggests installing symfony/event-dispatcher 
symfony/console suggests installing symfony/lock 
symfony/console suggests installing symfony/process 
symfony/console suggests installing psr/log (For using the console logger) 


Generating version class... 
...done generating version class 


Figura 2.2: Instalando o pacote laminas-migration em modo global 


Se a saída em seu terminal for semelhante a essa, o pacote laminas- 
migration foi instalado corretamente. Agora precisamos adicionar o 
diretório vendor/bin em nosso ambiente. Para fazer isso, execute o 
comando a seguir: 


composer global config home 


Esse comando mostrará onde o composer está instalado 
globalmente em seu sistema operacional. Copie o caminho que foi 
exibido e vamos adicionar a variável de ambiente em nosso sistema. 
Para isso, abra o seu arquivo $HOME/.bashrc e cole o código a seguir 
no final dele: 


export PATH=/home/SEU USUARIO/.composer/vendor/bin: $PATH 


O conteúdo do Path é exatamente o código que você copiou, onde 
seja, é o local onde seu composer está instalado. Você deve 
completar o caminho apontando para o diretório vendor/bin , 
conforme mostrado no código anterior. Salve e feche o arquivo. 


Entre no diretório raiz do seu projeto e execute o comando laminas- 
migration . Se o resultado obtido for semelhante ao exibido na 
imagem a seguir, então estamos prontos para iniciar o processo de 
migração: 


$ laminas-migration 
laminas-migration 


command [options] [arguments] 


Display this help message 

Do not output any message 

Display this application version 

Force ANSI output 

Disable ANSI output 

Do not ask any interactive question 

Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug 


Displays help for a command 
Lists commands 


Migrate a project or third-party library to target Laminas, API Tools, or Mezzio 
Update project to require Laminas-variants of nested Zend Framework package dependencies. 





Figura 2.3: Verificando a instalacáo do pacote laminas-migration 


2.2 Executando o comando de migracáo 
Para iniciar o processo de migracáo basta executar o comando a 
seguir na raiz de seu projeto: 


laminas-migration migrate 


Após a execução do comando anterior você verá uma saída 
semelhante a apresentada na imagem a seguir, indicando que a 
migração foi realizada com sucesso: 


- Perform a diff to verify the changes made. 
- Run “composer install". 
- Run any tests (unit tests, integration tests, end-to-end tests, etc.). 





Figura 2.4: Processo de migração concluído 


Caso tenha ocorrido algum erro no processo de migração, tente 
conceder permissão ao seu projeto e tente novamente. 


Após a conclusão do processo de migração você pode 
opcionalmente verificar as alterações utilizando o comando git 
diff. 


Perceba que o Laminas pede que executemos o comando composer 
install para realizar a instalação das dependências do nosso 
projeto, então execute-o e aguarde o término da instalação. Perceba 
que agora os pacotes que possuíam o nome zendframework 

passaram a ter o nome lamina NO começo. 


Com isso, finalizamos a migração do nosso projeto para o Laminas. 


Se você deseja obter mais informações sobre o processo de 
migração, você poderá conferir a documentação oficial da migração 
para o Laminas no URL a seguir: https://docs.laminas.dev/migration. 


Conclusão 


Vimos como podemos realizar a migração do nosso projeto em 
Zend Framework para o Laminas. Não é um processo difícil e nem 
muito trabalhoso, basta termos a atenção para fazer as 
configurações necessárias para realizar a migração de maneira 
bem-sucedida. 


No próximo capítulo, conheceremos mais sobre os frameworks full 
stack e os microframeworks, então siga em frente e vamos nessa! 


CAPITULO 3 
Frameworks full stack vs. microframeworks 


Neste capítulo, vamos abordar diferenças e características de 
frameworks full stack e microframeworks, quais as vantagens e 
desvantagens de cada um dos tipos, exemplos e quando utilizar um 
ou outro. É importante conhecer as diferenças entre eles para que 
não haja confusão, então siga em frente! 


3.1 Framework full stack 


Framework full stack é um conjunto completo de bibliotecas 
disponibilizadas para atender as mais variadas necessidades do dia 
a dia do desenvolvedor, desde a criação de views, MVC (Model 
View Controller), paginação, abstração da camada de banco de 
dados, filtros, validações e entre outras diversas bibliotecas. Para 
que você entenda melhor, um conjunto de classes e métodos 
formam uma biblioteca; e um conjunto de bibliotecas, seguindo 
alguns padrões, conceitos e arquiteturas bem-definidas e testadas, 
formam um framework. 


MVC (MODEL VIEW CONTROLLER) - é um padrão de arquitetura 
de software que visa separar a aplicação em 3 camadas: Model, 
responsável pela regra de negócio da aplicação, é quem realiza 
a interação com o banco de dados; View, responsável por 
apresentar as informações na tela para o usuário; Controller, 
responsável pela mediação entre as camadas de Model e View, 


ou seja, essa camada obtém os dados do banco de dados 
através da Model e repassa esses dados para a camada da 
View. 


Views - Nada mais são do que páginas de exibição de 
informações, podendo ser em PHP, HTML, XHTML, PHTML etc. 





Como mencionado anteriormente, tudo o que conhecemos hoje em 
dia possui suas vantagens e desvantagens. Vamos conhecer então 
algumas vantagens e desvantagens dos frameworks full stack: 


Vantagens 


e Conjunto completo de bibliotecas - lembre-se de que uma 
biblioteca é um conjunto de classes e métodos que seguem 
uma determinada lógica para solucionar um determinado 
problema, logo bibliotecas de: validação e filtragem de dados, 
autenticação de usuários, envio de e-mails, criação de logs, 
paginação, estrutura MVC, dentre muitas outras, já são 
instaladas com o framework full stack. Com isso, o trabalho do 
desenvolvedor torna-se mais simples, já que não há muitos 
motivos para vasculhar a internet atrás de uma biblioteca 
compatível com a necessidade exigida pelo projeto. 


e Estrutura MVC definida - a estrutura padrão para a criação do 
projeto seguindo o modelo MVC já vem definida e bem testada, 
facilitando na criação da lógica do projeto. Quem já trabalhou 
com MVC completamente do zero sabe que não é tão 
complicado, mas é um pouco trabalhoso. Já com a mesma 


estrutura definida pelo próprio framework fica bem mais simples 
e muito menos trabalhoso de se criar a lógica. 


Desvantagens 


e Nem todas as bibliotecas instaladas com o framework 
serão utilizadas - apesar de ser uma grande vantagem, ter 
todas as bibliotecas instaladas com o framework acaba se 
tornando uma desvantagem também, pois nem todas as 
bibliotecas instaladas serão utilizadas em um projeto afetando a 
performance do sistema. É o mesmo que instalar um framework 
full stack para criar apenas um site simples que não requer 
tanta tecnologia. 

e Alta curva de aprendizagem - um framework full stack requer 
um estudo mais aprofundado para que se domine com sucesso 
seus recursos e funcionalidades, e por ser maior e mais 
completo, estudar a documentação completa demanda muito 
tempo que hoje em dia é tão raro quanto água no deserto. 

e Maior tempo e complexidade para criar novas 
funcionalidades - se estudar toda a documentação de um 
framework full stack demanda tempo, também acontece de 
alguns recursos levarem muito mais tempo para serem 
implementados com sucesso, principalmente se a 
documentação não for tão boa. 


Características 


Cada framework desenvolvido possui características peculiares que 
podem atender ou não as necessidades do desenvolvedor. Por isso, 
antes de optar por algum framework e incorporá-lo ao projeto que 
será desenvolvido, você deve levar em consideração as suas 
características. Por exemplo, algumas características podem ajudar 
você a decidir na tomada de decisão no momento da escolha de um 
framework são: 


e Performance - a performance do framework para executar uma 
determinada ação é boa o suficiente para atender ao projeto 


que sera desenvolvido? 

Integração de bibliotecas de terceiros ao framework - é facil 
integrar bibliotecas de terceiros ao framework ou requer um 
custo a mais de mão de obra? 

Criação de recursos - a criação de recursos como: rotas, 
páginas, logs, conexões com banco de dados, validações, 
formulários, autenticação e entre outros é complexa ou não 
requer tanto esforço? 

Configurações - definir as configurações é claro o suficiente 
para o desenvolvedor e toda a equipe? 

Baixo acoplamento - um projeto desenvolvido no framework 
pode ser incorporado facilmente em outros, sem muito trabalho, 
ou sua arquitetura é muito restrita e só pode ser incorporada a 
outros projetos desenvolvidos com o mesmo framework? 
Testes do framework - o framework está testado o suficiente 
para ter uma boa cobertura de testes que garante o 
funcionamento estável? 

Documentação - a documentação é bem escrita e de fácil 
entendimento e compreensão ou você tem que ficar caçando 
agulha no palheiro? 


Essas características devem ser analisadas para que, em um futuro 
próximo, não se tenha uma grande dor de cabeça, seja por 
problemas de performance, flexibilidade e, nos casos mais 
extremos, estar utilizando um framework que será ou foi 
descontinuado. Tivemos esse problema na empresa em que 
trabalho. Tínhamos vários sistemas desenvolvidos em Silex e, em 
um belo dia, vimos que ele foi descontinuado. Nós tínhamos duas 
opções: 


1. Continuar utilizando o Silex sem ter suporte do desenvolvedor e 


correr o risco de o sistema ficar defasado e completamente 
ultrapassado, ou 


2. Investir custo e mão de obra para migrar pouco a pouco todos 


os sistemas para um outro framework que atenda todas as 
necessidades. 


Felizmente, optamos por fazer a migração para um novo framework; 
no caso da empresa, o Symfony 4 foi o escolhido. Então, antes de 
escolher o framework para desenvolver o seu projeto, verifique o 
máximo que puder as informações e características, veja se o 
framework não corre o risco de ser descontinuado, acompanhe as 
releases do projeto etc. para que você não tenha um problema 
parecido com o que tivemos na empresa, OK? 


Exemplos de frameworks full stack para PHP 


e Zend Framework - é um framework que possui uma grande 
variedade de bibliotecas desenvolvidas pela própria Zend e é 
bastante flexível pois é fácil integrar bibliotecas de terceiros ao 
projeto. É indicado para a criação de projetos de nível 
intermediário a avançado, pois sua estrutura complexa se torna 
inviável em sistemas muito simples, devido à sua curva de 
aprendizagem e, principalmente, ao tamanho do framework 
(todas as bibliotecas serão instaladas e nem todas serão 
utilizadas, e isso acaba afetando a performance do projeto). 
Vale lembrar que o Zend Framework foi abandonado e não terá 
mais atualizações. 


e Laminas - é o sucessor oficial do ecossistema Zend Framework 
que, como dito anteriormente, foi abandonado pela Zend/Rogue 
Wave Software e hoje está aos cuidados de um comitê técnico 
e futuramente passará a ser liderado pela Linux Foundation. O 
Laminas possui basicamente a mesma estrutura do Zend 
Framework 3, tendo o nome dos pacotes alterados para manter 
a compatibilidade com o seu antecessor. Então quem estava 
familiarizado com o Zend Framework não terá dificuldades em 
utilizar o Laminas. 


e Symfony - é um framework desenvolvido pela SensioLabs e 
hoje é um dos mais utilizados dentro da comunidade PHP, 
assim como o Zend Framework. O Symfony também possui 
uma grande variedade de bibliotecas desenvolvidas pela 
SensioLabs e também é bastante flexível quanto a utilização de 


bibliotecas de terceiros. É indicado para a criação de aplicações 
simples até as mais complexas, pois a partir do Symfony 4 
pode-se fazer a instalação mínima sem ter toda a estrutura 
complexa do framework, o que o torna mais leve, dependendo 
do projeto que será desenvolvido. 


e Laravel - é um dos frameworks que conquistou muitos 
desenvolvedores nos últimos anos e sua comunidade cresceu 
muito devido à sua facilidade de instalação, configuração e pela 
sua documentação. É indicado desde os projetos mais simples 
até os mais complexos, pois sua estrutura é de fácil 
entendimento e não demora muito para criar um projeto em 
Laravel. Também é um framework flexível quanto à instalação 
de bibliotecas de terceiros, porém é necessário um 
conhecimento de Facades para utilizar com mais coesão os 
recursos do framework. 


3.2 Microframework 


Pode-se entender como microframework um conjunto mínimo de 
funcionalidades que possam atender a determinada necessidade. 
Ou seja, um microframework é voltado para solucionar apenas um 
determinado problema, como criação de APIs, templates e entre 
outros. Não é necessário termos toda a estrutura complexa de um 
framework full stack para a criação de um projeto de API, por 
exemplo. A estrutura mínima concedida pelo microframework já é o 
suficiente. Está confuso? Não se preocupe, na seção Quando 
utilizar framework full stack ou microframework você poderá ver uma 
tabela comparativa entre frameworks full stack e microframeworks. 


Assim como os frameworks full stack, os microframeworks também 
possuem as suas vantagens e desvantagens. Vamos ver algumas 
delas a seguir: 


Vantagens 


e Baixo nivel de complexidade - a estrutura definida é mais 
simples e, consequentemente, o desenvolvimento dos recursos 
e lógica são algo muito mais fácil do que em uma estrutura 
complexa como a de um framework full stack. 


e Baixa curva de aprendizagem - por ser menor e possuir uma 
estrutura minimalista, a curva de aprendizagem é algo muito 
baixo, pois não requer uma leitura bem aprofundada na 
documentação para começar o desenvolvimento. 


e Performance - como são instalados somente o necessário para 
garantir o funcionamento do microframework, a sua 
performance é maior que a de um framework full stack, já que 
temos apenas o necessário e o essencial para começar o 
trabalho. 


e Agilidade na criação de aplicações de mínima e alta escala 
- desenvolver com um microframework é algo muito mais rápido 
devido ao fato de sua curva de aprendizagem ser 
extremamente baixa. Com isso, as aplicações ficam prontas em 
menor tempo e, claro, com menor custo também. 


Desvantagens 


e Encontrar um recurso ou biblioteca compatível pode ser 
trabalhoso - às vezes, pode ocorrer de algumas bibliotecas 
não serem compatíveis com a estrutura do microframework, 
principalmente se a estrutura teve uma mudança radical. 
Encontrar alguma biblioteca similar ou genérica pode exigir 
tempo e trabalho consideráveis. 


e Alguns microframeworks podem ter documentação 
escassa - já encontrei na internet microframeworks cuja 
documentação era extremamente escassa e, para entender um 
determinado componente, tive que procurar muito em nossos 
queridos pais Google e Stack Overflow. Já houve casos em que 


o único modo para conhecer melhor era o famoso debug do 
código, imagine quanto tempo seria economizado se tivesse 
uma boa documentação? Muito tempo! 


Características 


No momento de optar pelo microframework para o desenvolvimento 
de um projeto, também é importante observar e atentar-se as 
características de cada um. Vamos verificar a seguir algumas 
características que podem ajudar você a decidir qual 
microframework utilizar: 


e Complexidade - a estrutura do microframework que você está 
analisando é mais ou menos complexa do que outros a serem 
analisados? 

e Performance - é performático o suficiente para o projeto a ser 
desenvolvido? 

e Implantação - é fácil de ser implantado em outros ambientes, 
como: ambientes de desenvolvimento, de homologação, de 
testes e de produção”? Requer muito tempo para fazer essa 
implantação ou é algo rápido? 

e Bibliotecas - existem bibliotecas compatíveis que se adequam a 
estrutura do microframework e com o que deverá ser 
desenvolvido? Ou você terá que perder um certo tempo em 
busca de algo compatível e/ou mais genérico? 

e Documentação - a documentação é bem escrita e de fácil 
entendimento e compreensão ou é escassa de fazer você 
chegar ao ponto de debugar o código para entender seu 
funcionamento? 


Exemplos de microframeworks para PHP 


e Zend Expressive - foi desenvolvido pela Zend, e possui o 
objetivo de facilitar o desenvolvimento de APIs e aplicações 
simples ou até mesmo de aplicações complexas sem haver a 
necessidade de ter uma estrutura tão bem-definida e complexa 
quanto a do Zend Framework. Além disso, a documentação é 


muito boa e também possui uma excelente flexibilidade, 
permitindo a instalação de bibliotecas de terceiros. Vale lembrar 
que o Zend Expressive também foi abandonado e não terá mais 
atualizações. 


Mezzio - o protagonista deste livro é o sucessor oficial do Zend 
Expressive e possui a mesma estrutura minimalista que o seu 
antecessor. Se você já estava familiarizado com a estrutura do 
Zend Expressive você não terá nenhum problema e verá que as 
dependências que tinham o nome zendframework , passaram a se 
chamar laminas . À performance também foi mantida. 


Slim - é um dos primeiros microframeworks com que trabalhei 
para desenvolver uma API e sua estrutura é bastante simples e 
quase não requer muito estudo para iniciar o desenvolvimento; 
realmente é simples e bastante flexível. 


Silex (já descontinuado) - como mencionado anteriormente, o 
Silex foi desenvolvido pelo mesmo criador do Symfony e sua 
estrutura também é muito simples e muito fácil de ser 
compreendida, além disso, era compatível com muitas 
bibliotecas e a documentação não era escassa. 


Lumen - desenvolvido pelo criador do Laravel, possui uma 
estrutura bem simples e também não é muito demorado para 
começar a desenvolver com ele. Criar APIs com ele é bem 
rápido e não demanda muito tempo de estudo, pois sua 
documentação é muito boa. 


3.3 Quando utilizar framework full stack ou 
microframework 


Provavelmente você deve estar se perguntando: Jhones, como 


decido qual utilizar? Primeiramente, você tem que identificar qual o 


tipo de problema que devera ser solucionado, ou seja, depende do 
tipo de projeto que devera ser desenvolvido. 


Por exemplo, se o projeto for apenas para fornecer informações por 
meio de consultas rápidas, como uma consulta rápida pelo nome de 
uma pessoa, ou CEP, ou até mesmo verificar o score de uma 
pessoa no SPC (Serviço de Proteção ao Crédito), a melhor escolha 
seria um microframework, já que a estrutura minimalista dele lhe 
fornece maior facilidade do que um framework full stack. Agora, se 
você for desenvolver um e-commerce ou um portal mais complexo, 
por exemplo, um framework full stack seria a melhor opção. Para 
melhor entendimento, veja a seguir uma comparação entre 
framework full stack e microframework: 


Frameworks full stack 


e Quando usar: indicado para projetos mais extensos, 
complexos que requerem mais tecnologia e uma estrutura mais 
definida. 

e Estrutura: completa e mais complexa. 

e Tipos de aplicações: portais, e-commerces, CMS e dentre 
outros tipos de aplicações que requerem mais tecnologia. 

e Exemplos: Zend Framework (abandonado), Laminas, Symfony, 
Laravel. 


Microframeworks 


e Quando usar: indicado para projetos mais simples ou que 
atendam a uma determinada demanda. 

e Estrutura: minimalista e mais simples. 

e Tipos de aplicações: APIs, projetos mais simples que não 
requerem uma estrutura bem-definida quanto a de um 
framework full stack. 

e Exemplos: Slim, Silex (já descontinuado), Zend Expressive 
(abandonado), Mezzio, Lumen, Twig. 


É importante ressaltar que não existe uma regra específica que nos 
obrigue a utilizar um framework full stack para desenvolver uma API, 


ou um microframework para desenvolver uma aplicação mais 
complexa. O que existe são conceitos que se aplicam a um 
determinado projeto para que seja mais fácil escolher com qual dos 
dois tipos trabalhar. Lembre-se de que o tipo de framework e qual 
utilizar dependerá de dois fatores extremamente importantes: 
projeto e prazo. 


Então, não se esqueça: microframeworks para criação de APIs, 
microsserviços ou até mesmo aplicações de mínima ou alta escala; 
framework full stack para projetos mais extensos e complexos como 
portais, e-commerces, CMS etc. Também não deixe de considerar 
as vantagens, desvantagens e características de cada framework 
full stack ou microframework no momento da escolha. 


Conclusão 


Neste capítulo, vimos o que é um framework full stack e o que é um 
microframework, juntamente com algumas de suas vantagens e 
desvantagens. Vimos também exemplos de frameworks full stack e 
exemplos de microframeworks, e ainda vimos um comparativo entre 
ambos para explicitar algumas diferenças e justificar por que utilizar 
determinado tipo ou outro. Como foi mencionado, a escolha de um 
framework ou microframework depende muito de dois fatores muito 
importantes: projeto e prazo. Foi citado um exemplo real do que 
aconteceu na empresa em que trabalho para que você pudesse ter 
a visão de como a escolha cautelosa é um ponto vital antes de 
desenvolver qualquer projeto. 


No próximo capítulo entenderemos sobre SOAP, REST, RESTful e 
API. Veremos brevemente alguns pontos importantes sobre esses 
termos, quais são suas aplicabilidades em nosso dia a dia e muito 
mais. Vamos nessa! 


CAPITULO 4 
Explorando APIs, SOAP, REST e RESTful 


Nao ha como falarmos de APIs sem conhecermos parte da historia 
da Web, seus conceitos, suas definições, seus funcionamentos e os 
componentes de uma API. E exatamente isso que veremos logo a 
seguir. 


4.1 API (Application Programming Interface) 


API (Application Programming Interface), ou Interface de 
Programação de Aplicativos em português, é um conjunto de 
padrões e rotinas bem-definidas para atender as necessidades de 
uma empresa em fornecer dados específicos para aplicações 
externas. Resumidamente, uma API é criada para que outras 
aplicações possam fazer a comunicação independentemente da 
plataforma para obter os resultados de acordo com a requisição. 


Uma API contém inúmeros serviços que fornecem dados de acordo 
com o que for requisitado, por exemplo: uma API que fornece dados 
meteorológicos da situação climática do nosso país poderá conter 
serviços de temperatura, medição da qualidade do ar, medição de 
raios UV (ultravioleta) dentre muitos outros. O cliente que solicitar a 
requisição poderá ter acesso a todos os serviços ou apenas alguns 
deles, isso depende do tipo de permissão que a API implementa ou 
disponibiliza para os usuários. 


Empresas do mundo inteiro começaram a utilizar APIs para que 
houvesse mais compatibilidade com o maior número de plataformas 
possíveis e graças a elas, desenvolvemos apenas uma única vez 
para uma determinada plataforma e os clientes apenas fazem a 
comunicação. Uma vez que o cliente pode ser de qualquer tipo de 


plataforma como desktops, TVs, web, mobile, apenas sera 
responsável por fazer a requisição ao serviço sem se preocupar 
com a lógica que está na API. 


Você pode estar se perguntando: toda API é igual e serve para 
atender a mesma necessidade”? A resposta é "não" para ambas as 
perguntas, cada API atende um determinado problema. Lembre-se 
que uma API tem por objetivo fornecer serviços para que aplicações 
externas possam obter informações específicas, seja para mostrar 
ao usuário ou para tomar uma determinada decisão dentro da 
aplicação. 


4.2 SOAP (Simple Object Access Protocol) 


SOAP (Simple Object Access Protocol), ou Protocolo Simples de 
Acesso a Objetos em português, é um protocolo de comunicação 
para troca de mensagens baseado em XML (eXtensible Markup 
Language) permitindo que uma ou mais aplicações se comuniquem 
através do protocolo HTTP. 


Se você já trabalhou com XML então poderá pular essa pequena 
introdução. Basicamente, XML é uma linguagem de marcação 
semelhante ao HTML, com a diferença de que é você que define a 
estrutura que seu arquivo XML poderá ter. Há muitos exemplos de 
XML na internet e inclusive há exemplos de XML usados para 
carregar configurações da aplicação. 


Para quem não conhece, o protocolo HTTP (Hypertext Transfer 
Protocol), ou Protocolo de Transferência de Hipertexto em 
português, simplesmente é a base da comunicação na Web. Sabe 
aquele seu site preferido que você acessa ao digitar na barra de 
endereço de seu navegador? Pois bem, quando você digita o 
endereço do site no navegador, ele está fazendo uma comunicação 
HTTP para troca de informações, em que você solicita o acesso ao 


site e o servidor do site verifica a requisição e permite a 
transferência dos dados da página para o seu dispositivo 
(computador, notebook, smartphone, TV, dentre outros) que resulta 
na página completamente montada para você visualizar. 


Hoje em dia, há muitas empresas que utilizam o SOAP para fazer a 
comunicação entre as aplicações internas e externas por ele ser um 
protocolo bem-definido. 


Você pode estar se perguntando: mas como implemento o SOAP 
em meu projeto de API em PHP? Primeiramente, você precisa 
instalar a extensão do PHP: php7.2-soap OU php7.1-soap OU php5.6- 
soap . Esse modulo traz consigo algumas classes e uma série de 
métodos que você deverá utilizar para que sua API funcione por 
meio do modelo SOAP. Não será descrito detalhadamente como 
criamos uma API em SOAP, mas é preciso entender que o SOAP 
existe e é importante conhecer sobre esse protocolo. Principalmente 
se você vai iniciar com o desenvolvimento de APIs e até mesmo 
para realizar manutenção em APIs existentes ou somente fazer a 
comunicação com elas. 


O funcionamento do SOAP é bastante simples, podendo ocorrer de 
3 métodos ou padrões possíveis: GET, post e soap . Basicamente, o 
GET € O post são métodos HTTP e seu funcionamento é o mesmo, 
ou seja, o método cet é utilizado para obter dados, por exemplo, 
obter os dados de um determinado usuário. O método post é 
utilizado para fazer a gravação das informações no banco de dados, 
por exemplo, salvar os dados do cadastro de um usuário. Já o soap 
é como o post , porém com a diferença de que as requisições 
efetuadas devem possuir o formato xm. , ou seja, isso significa que 
todas as requisições serão sempre no formato XML. Para entender 
melhor o funcionamento entre as aplicações cliente e uma API 
SOAP, veja a imagem a seguir: 








FAZ A REQUISIÇÃO Aa 


OBTÉM A RESPOSTA EM XML SOAP API 





APLICACOES CLIENTE 


Figura 4.1: Funcionamento de API SOAP 


O esquema de comunicacáo náo é complicado. Basicamente, a 
aplicação cliente descobre o servico, faz a requisição e obtém a 
resposta do serviço. Não é do escopo deste livro entrar em detalhes 
aprofundados sobre o funcionamento detalhado de cada parte da 
estrutura de uma mensagem SOAP; para mais informações sobre o 
funcionamento do SOAP, você pode acessar o link 
https://www.devmedia.com.br/web-services/2873/, ou conferir nas 
referências deste mesmo livro. 


Mas por que será que o SOAP é um padrão extremamente utilizado 
no mundo inteiro? Quais são as suas vantagens e desvantagens? 


Vantangens 


e Funcionamento independente da plataforma - nao fica 
amarrado a apenas uma plataforma. Uma API em SOAP pode 
ser consumida e utilizada por todos os tipos de clientes 
(plataformas) sem a necessidade de fazer o desenvolvimento 
de código diferente para cada tipo de plataforma. 


e Alta interoperabilidade - a interoperabilidade com diversas 
plataformas é algo que funciona muito bem com SOAP, pois o 
modelo padrão de envio e resposta definidos (que é o xm ) 
facilita para que se tenha uma excelente comunicação entre as 
plataformas. 


e Fácil interpretação - é muito mais facil interpretarmos um 
arquivo que possui uma estrutura em xm do que analisar uma 
resposta em JSON (JavaScript Object Notation), por exemplo. 


Desvantagens 


e Possui um overhead a mais - além do cabeçalho da 
requisição HTTP, pode-se ter um cabeçalho SOAP com as 
mesmas informações, ou seja, causando uma certa 
redundância de informação. 


e É um pouco mais trabalhoso de ser implementado, 
dependendo da linguagem de programação - cada 
linguagem de programação tem sua característica para a 
implementação de leitura e escrita de xml , algumas mais 
trabalhosas do que outras. É necessário um certo nível de 
conhecimento para fazer a implementação. 


4.3 REST (Representational State Transfer) 


REST (Representational State Transfer), ou Transferência de Estado 
Representacional em português, é uma arquitetura baseada no 
protocolo de comunicação HTTP. Através dessa arquitetura é 


possível fazer com que as aplicações se comuniquem 
independentemente do tipo de plataforma que está sendo utilizada. 


A diferença entre REST e SOAP é simples: SOAP aceita apenas 
requisições no formato XML, já o REST, por ser totalmente baseado 
no HTTP, aceita vários tipos de requisições como: XML, JSON, 
binário e entre outros. Nesse aspecto, o REST é bastante flexível 
em comparação ao SOAP. 


Para entendermos o funcionamento de uma API REST imagine o 
seguinte cenário: você acessa sua conta do banco através do seu 
computador para verificar o seu saldo, porém em um determinado 
momento você não está diante do seu computador, mas está com 
seu smartphone em mãos e decide consultar novamente seu saldo 
no banco. Até aí tudo bem, você informa sua agência, conta e sua 
senha no app e você obtém o saldo da sua conta. 


A pergunta que faço é: o banco desenvolveu um mesmo serviço 
para cada tipo de plataforma existente, ou seja, um código para 
Windows, outro para Linux, outro para MAC, outro para Android? 
Não. 


O banco simplesmente desenvolveu uma API que fornece vários 
serviços para que aplicações desenvolvidas em diversas 
plataformas possam fazer a comunicação e obter a informação 
desejada. 


Para facilitar o entendimento de como funciona uma aplicação 
baseada em arquitetura REST, veja a imagem a seguir: 






APLICAÇÕES APLICAÇÕES 
APPLE WEB 
ud ES 
APLICAÇÕES APLICAÇÕES 
ANDROID WINDOWS 


Figura 4.2: Funcionamento de Aplicações REST 


Como podemos ver na imagem anterior, a API disponibiliza os 
serviços necessários para que todas as demais aplicações possam 
fazer a utilização, independentemente da plataforma que está 
solicitando a requisição, ou seja, não é necessário escrever um 
código específico para cada plataforma, basta desenvolver uma API 
que disponibilizará todos os serviços necessários, evitando mais 
trabalho e, consequentemente, mais investimentos. 


Para entendermos a estrutura básica de uma aplicação REST, 
vamos ver algumas características peculiares dessa arquitetura, 
como: 


e Client-Server - separação das responsabilidades entre cliente 
e servidor, o cliente não se preocupa com a lógica da API em si, 
apenas efetua as requisições. 


Stateless - um mesmo cliente pode fazer inúmeras requisições, 
mas o tratamento de cada requisição deve ser feito de forma 
independente, ou seja, cada requisição é tratada 
separadamente de acordo com as informações contidas nela. 


Cacheable - as respostas devem ser cacheadas para que não 
ocorram processamentos desnecessários, assim, quando 
houver outra requisição para obter o mesmo dado, ele já estará 
em cache e a resposta será mais rápida, já que não será 
necessário consultar novamente o banco de dados. 


Uniform Interface - a API deve ser baseada em interface ou 
contratos, como muitos preferem chamar, assim sua 
manutenibilidade se torna mais fácil. Basicamente, quanto mais 
genérica for a API, melhor será. 


Layered System - a aplicação deve ser baseada em camadas, 
fazendo com que a aplicação apenas se preocupe com a 
comunicação. E essa comunicação não deve ser feita 
diretamente com o servidor, mas sim com uma outra camada 
responsável pela comunicação com a aplicação. Geralmente, 
pode ser uma camada de load balancer que se responsabiliza 
pelo balanceamento de carga. 


Code On Demand (é opcional) - é opcional e náo faz parte da 
arquitetura propriamente dita, mas permite que o cliente 
execute código sob demanda. 


A simplicidade e a clareza da arquitetura REST fez com que muitas 
empresas rapidamente comecassem a desenvolver novos modelos 
de APIs, mas por qué? Quais as vantagens e desvantagens dessa 

arquitetura? 


Vantagens 


e Alto nivel de interoperabilidade - possui um alto nível de 
interoperabilidade com outros tipos de sistemas pois a 


comunicação funciona de forma semelhante ao SOAP, porém é 
baseado totalmente no HTTP. 


e Possui alta performance - é extremamente rápido, há quem 
diga que é mais rápido do que SOAP que possui um overhead 
a mais. Ambos são extremamente rápidos, depende muito do 
tipo de linguagem de programação que está sendo utilizada na 
construção da API e nos conceitos aplicados, mas em REST, 
por não se tratar de um envio de XML, as requisições 
costumam ser mais rápidas. 


e Flexibilidade - o desenvolvedor não fica amarrado apenas um 
tipo de requisição, como é o caso do SOAP, em que as 
requisições são feitas em XML. As requisições em REST 
podem ser feitas de outras maneiras; o padrão é o JSON, mas 
pode-se ter binário, XML entre outros. REST permite que você 
desenvolva da maneira que desejar, por isso é altamente 
flexível. 


Desvantagens 


e É necessário um conhecimento básico - para fazer a leitura 
dos dados, já que os dados não estão dentro de uma TAG 
como no SOAP. A maioria das APIs REST devolve a resposta 
em formato JSON 


e Perda da interoperabilidade - por ser flexível, deve-se tomar 
cuidado para não perder a interoperabilidade pois tudo tem que 
ser pensado corretamente para que os devidos erros possam 
ser capturados e tratados adequadamente para que as 
aplicações clientes não obtenham erros que não foram tratados 
pela API. 


Assim como o SOAP, o REST é uma arquitetura muito poderosa que 
se bem implementada poderá alcançar resultados incríveis e 
plenamente satisfatórios. Mais adiante teremos um capítulo em que 
faremos uma API simples de CRUD de usuários para que você 
possa fixar o conhecimento da melhor maneira possível. 


RESTful 


RESTful nada mais é do que a implementação da arquitetura REST, 
ou seja, é colocar em prática os embasamentos e características do 
REST na API que está sendo desenvolvida. 


Não basta apenas desenvolver os serviços em GET, POST, PUT, 
PATCH, DELETE € achar que você já possui uma API RESTful, pois 
para isso é necessário seguir os conceitos da arquitetura REST de 
forma coesa. Também há níveis em que os conceitos do REST 
mencionados anteriormente devem ser aplicados, chamados de 
Richardson Maturity Model. Para que você possa conhecer melhor 
sobre esses níveis, acesse o link: 
https://martinfowler.com/articles/richardsonMaturityModel.html/. 
Nele, tem uma descrição bem detalhada de cada nível, mas vamos 
ver uma breve explicação: 


e Nível O - ausência de regras; 

e Nível 1 - deve possuir resources (recursos); 

e Nível 2 - utilização dos verbos HTTP, para uma mesma URI 
pode-se ter verbos diferentes, por exemplo: cer /usuários, post 
/usuarios; 

e Nivel 3 - fornecimento de informações necessárias para o 
cliente para que a comunicação seja feita entre cliente-servidor, 
HATEOAS (Hypertext As The Engine Of Application State). 


Se a API atender todos esses conceitos do Richardson Maturity 
Model e todas as características do REST mencionadas 
anteriormente, então ela é uma API RESTful. Não faremos um 
projeto mostrando como construir uma API RESTful, mas saiba da 
existência desse conceito, pois é muito utilizado nos dias de hoje. 


Conclusão 


Abordamos neste capítulo alguns conceitos e arquiteturas como: 
SOAP, REST, RESTful e API que são os principais assuntos para a 
construção de uma API. Conforme vimos, uma API fornece uma 


variedade de serviços para que aplicações cliente possam fazer a 
comunicação e obter as informações solicitadas. Mais adiante 
veremos mais detalhes durante a construção da nossa API. No 
próximo capítulo vamos iniciar a preparação do nosso ambiente de 
desenvolvimento. 


CAPITULO 5 
Preparando o ambiente 


Antes de iniciarmos nosso projeto, precisamos preparar o nosso 
ambiente. Aqui será demonstrado o passo a passo no Linux e no 
Windows, mas caso você utilize MAC, a instalação é bem 
semelhante à do Linux. Se preferir, pode conferir um passo a passo 
da instalação completa em MAC no link: 
https://www.google.com.br/amp/s/coolestguidesontheplanet.com/inst 
all-apache-mysql-php-and-phpmyadmin-on-macos-high-sierra-10- 
13/amp/. 


5.1 Linux 


Se vocé utiliza o Linux baseado em uma distribuicáo Debian (como 
Ubuntu 14.04, 16.04, 17.04, 18.04, 19.04, Mint, Kubuntu etc.) basta 
seguir os passos descritos a seguir: 


Instalando Apache2 
Neste livro vamos utilizar o Apache2 porque é um dos servidores 


mais utilizados no mundo, além de ser fácil de configurar. 


O QUE É APACHE2? 


Nada mais é do que um servidor Web gratuito e de código livre. 





Para instalar o Apache2 execute os comandos a seguir: 


sudo apt-get update 
sudo apt-get install apache2 


Será exibida uma lista dos pacotes que serão instalados. Pressione 
Y € ENTER para confirmar a instalação. Após o término, se tudo 
ocorreu bem, você deve digitar em seu navegador: http://localhost 
e a página a seguir deverá ser exibida: 





Q, httpy/localhost| ->| | Q search 











Ubuntu Logo 


Apache2 Ubuntu Default Page 


This is the default welcome page used to test the correct operation of the Apache2 server after 
installation on Ubuntu systems. It is based on the equivalent page on Debian, from which the Ubuntu 
Apache packaging is derived. If you can read this page, it means that the Apache HTTP server 
installed at this site is working properly. You should replace this file (located at /var/www 
/html/index.html) before continuing to operate your HTTP server. 


If you are a normal user of this web site and don't know what this page is about, this probably means 
that the site is currently unavailable due to maintenance. If the problem persists, please contact the 
site's administrator. 


Configuration Overview 


Ubuntu's Apache2 default configuration is different from the upstream default configuration, and split 
into several files optimized for interaction with Ubuntu tools. The configuration system is fully 
documented in /usr/share/doc/apache2/README. Debian.gz. Refer to this for the full 
documentation. Documentation for the web server itself can be found by accessing the manual if the 
apache2-doc package was installed on this server. 


The configuration layout for an Apache2 web server installation on Ubuntu systems is as follows: 


: /etc/apache2/ 

: |-- apache2. conf 

: “-- ports.conf 
-- mods-enabled 


| 

| |-- *. load 
| `=- * conf 
' |-- conf-enabled 
| “-- * conf 

|-- sites-enabled 
i | “-- * conf 





Figura 5.1: Página inicial do Apache2 


Com o éxito da instalacáo do Apache2 podemos seguir para o 
próximo passo. 


Instalando o MySQL 


Vamos utilizar o MySQL porque é fácil e náo requer muitas 
configurações e um conhecimento mais aprofundado, e até mesmo 


quem esta começando a trabalhar com banco de dados pode 
aprendê-lo facilmente em algumas poucas horas. O MySQL atende 
perfeitamente o que vamos desenvolver no decorrer deste livro. 


O QUE É MYSQL? 


É um banco de dados relacional responsável por realizar o 
armazenamento de informações. 





Para instalar o MySQL basta executar o comando a seguir: 


sudo apt-get install mysql-server 


Novamente, será exibida uma lista dos pacotes que serão 
instalados, e para confirmar a instalação tecle y e enter . Durante o 
processo, será solicitado que você informe uma senha para o banco 
de dados que será utilizada para fazer o acesso local para seu 
devido gerenciamento, conforme mostra a imagem a seguir: 


cage configu ration 


Configuring mysql-server-5.7 
While not mandatory, it is highly recommended that you set a password 
for the MySQL administrative "root" user. 


If this field is left blank, the password will not be changed. 


New password for the MySQL "root" user: 





Figura 5.2: Informando a senha do usuário no MySQL 


Após informar a senha, será solicitado que você a redigite. Com 
isso, a instalação do MySQL prosseguirá normalmente. Quando a 


instalação estiver finalizada, poderemos seguir para o próximo 
passo. 


Instalando o PHP 


Para fazer a instalação do PHP, primeiramente vamos adicionar o 
repositório do PHP para que o Linux o reconheça e possa fazer sua 
instalação. Para isso, execute o comando a seguir: 


sudo add-apt-repository ppa:ondrej/php 


Após ter adicionado o repositório do PHP, execute o comando a 
seguir para atualizar as dependências de seu Linux: 


sudo apt-get update 


MAS O QUE SÃO ESSAS DEPENDÊNCIAS? 


São pacotes/bibliotecas que são requeridos para a instalação de 
um outro pacote/biblioteca. 





Sempre que adicionarmos um novo repositório no Linux, devemos 
fazer a atualização das dependências para que o repositório que foi 
adicionado tenha os pacotes/bibliotecas disponíveis para instalação. 


Depois que as dependências do seu Linux estiverem atualizadas, 
podemos instalar o nosso PHP e algumas bibliotecas que serão 
necessárias para o nosso projeto: 


sudo apt-get install php7.4 php7.4-mysql php7.4-json php7.4-curl php7.4- 
xml php7.4-mbstring libapache2-mod-php7.4 


O QUE SAO BIBLIOTECAS? 


Sáo pacotes que contém códigos específicos que atendem uma 
determinada tarefa para a resolucáo de um problema. 





A seguir, vocé pode conferir a lista das bibliotecas/pacotes que 
instalaremos em nosso ambiente: 


e php7.4 - contém o PHP propriamente dito. 

e php7.4-mysql - responsável por realizar a comunicação do PHP 
com o MySQL, esse é o driver do MySQL para o PHP. 

e php7.4-json - pacote responsável por fornecer o módulo JSON 
para o PHP para que seja possível trabalhar com o formato 
JSON. 

e php7.4-curl - responsável por efetuar as requisições. Como 
vamos trabalhar com API, devemos ter esse módulo instalado 
para que essas requisições possam ser efetuadas pelo PHP. 

e php7.4-xml - esse pacote é responsável por disponibilizar a 
manipulação de arquivos XML através de classes e funções 
específicas. 

e php7.4-mbstring - responsável por tratar codificações baseadas 
em Unicode, por exemplo UTF-8 e muitas outras. 

e libapache2-mod-php7.4 - pacote responsável por fornecer o 
módulo PHP para o servidor Apache2. 


O sistema informará que serão instaladas várias dependências 
referentes aos pacotes do PHP que desejamos instalar. Tecle y e 
ENTER para confirmar a instalação. Se não ocorreram erros durante 
a instalação, o seu PHP está instalado e pronto para ser utilizado. 
Caso tenha ocorrido algum erro, por favor reveja os passos 
descritos e tente novamente. 


Para verificar se o PHP está corretamente configurado vamos criar 
um pequeno script que trará as informações do PHP que acabamos 
de instalar. Crie um arquivo chamado info.php dentro do diretório 
/var/www/htm1/ COM O seguinte conteúdo: 


<?php 
phpinfo(); 


Salve o arquivo e em seu navegador digite: http://localhost/info.php/. 
Se tudo ocorreu bem, vocé vera uma pagina semelhante a 


apresentada a seguir: 


Php 











System Linux mint 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 

Build Date Feb 5 2020 16:50:38 

Server API Apache 2.0 Handler 

Virtual Directory Support disabled 

Configuration File (php.ini) Path Jetc/php/7.4/apache2 

Loaded Configuration File Jetc/php/7.4/apache2/php.ini 

Scan this dir for additional .ini files Jetc/php/7.4/apache2/conf.d 

Additional .ini files parsed Jetc/php/7.4/apache2/conf.d/10-mysqlnd.ini, /etc/php/7.4/apache2/conf.d/10-opcache.ini, /etc/php 


/7.4Japache2/conf.d/10-pdo.ini, /etc/php/7.4/apache2/conf.d/15-xml.ini, /etc/php/7.4/apache2/conf.d 
/20-amqp.ini, /etc/php/7.4/apache2/conf.d/20-bcmath.ini, /etc/php/7.4/apache2/conf.d/20-bz2. ini, 
Jetc/php/7.4/apache2/conf.d/20-calendar.ini, /etc/php/7.4/apache2/conf.d/20-ctype.ini, /etc/php 
/7.AJapache2/conf.d/20-curl.ini, /etc/php/7.4/apache2/conf.d/20-dom.ini, /etc/php/7.4/apache2 
/conf.d/20-exif.ini, /etc/php/7.4/apache2/conf.d/20-ffi.ini, /etc/php/7.4/apache2/conf.d/20-fileinfo.ini, 
Jetc/php/7.4/apache2/conf.d/20-ftp.ini, Jetc/php/7.4/apache2/conf.d/20-gd.ini, /etc/php/7.4/apache2 
/conf.d/20-gettext.ini, /etc/php/7.4/apache2/conf.d/20-gmp.ini, Jetc/php/7.4/apache2/conf.d/20- 
iconv.ini, /etc/php/7.4/apache2/conf.d/20-intl.ini, /etc/php/7.4/apache2/conf.d/20-json.ini, /etc/php 
/7.4Japache2/conf.d/20-Idap.ini, /etc/php/7.4/apache2/conf.d/20-mbstring. ini, /etc/php/7.4/apache2 
/conf.d/20-mongodb. ini, Jetc/php/7.4/apache2/conf.d/20-mysqli.ini, /etc/php/7.4/apache2/conf.d/20- 
pdo mysql.ini, /etc/php/7.4/apache2/conf.d/20-pdo pgsql.ini, /etc/php/7.4/apache2/conf.d/20- 
pgsql.ini, /etc/php/7.4/apache2/conf.d/20-phar.ini, /etc/php/7.4/apache2/conf.d/20-posix.ini, 
/etc/php/7.4/apache2/conf.d/20-readline.ini, /etc/php/7.4/apache2/conf.d/20-shmop.ini, /etc/php 

/7 .4/apache2/conf.d/20-simplexml.ini, /etc/php/7.4/apache2/conf.d/20-soap. ini, /etc/php 
/7.4/apache2/conf.d/20-sockets.ini, /etc/php/7.4/apache2/conf.d/20-sysvmsg.ini, /etc/php 
/7.4/apache2/conf.d/20-sysvsem. ini, /etc/php/7.4/apache2/conf.d/20-sysvshm. ini, /etc/php 
/7.4Japache2/conf.d/20-tokenizer.ini, /etc/php/7.4/apache2/conf.d/20-xmlreader.ini, /etc/php 

/7 4/apache2/conf.d/20-xmlwriter.ini, /etc/php/7.4/apache2/conf.d/20-xsl.ini, /etc/php/7.4/apache2 
/conf.d/20-zip.ini 


PHP API 20190902 
PHP Extension 20190902 











Figura 5.3: Informações do PHP 


Com isso, já teremos instalado o essencial para trabalharmos com o 
PHP. 


5.2 Windows 


Se vocé é usuário do Windows, nós vamos utilizar o Wamp Server, 
que já vem com o Apache + MySQL + PHP. O processo de 
instalacáo é bem simples, basta fazer o download no site oficial do 
fabricante: http://www.wampserver.com/en/. Após o download ter 
sido concluído com sucesso, abra o arquivo baixado e avance até o 
final. Basta aguardar o término da instalacáo, que o Apache + 
MySQL + PHP já estaráo instalados e prontos para uso em sua 


maquina. Depois que a instalação do Wamp estiver concluída, em 
seu navegador, você poderá digitar http://localhost na barra de 
endereço. Se tudo ocorreu bem, a página inicial do Wamp deverá 
ser exibida conforme mostra a imagem a seguir: 


2 


WampServer 


Version 3.2.0 - 64bit | english v | classic v 


Server Configuration 
Apache Version: 2.4.41 - Documentation 
Server Software: Apache/2.4.41 (Win64) PHP/7.4.0 - Port defined for Apache: 80 
PHP Version: 7.4.0 - Documentation 


Loaded Extensions: * apache2handler e bcmath e bz2 e calendar 
® com dotnet e Core e ctype e curl 
e date e dom e exif e fileinfo 
e filter e gd e gettext e gmp 
e hash e iconv e imap e int 
® json e idap e libxml e mbstring 
e mysqli e mysqind ® openssl e pcre 
e PDO e pdo mysql e pdo sqlite e Phar 
e readline e Reflection ® session e SimpleXML 
® soap e sockets e SPL e sqlite3 
e standard e tokenizer e xdebug e xml 
e xmlreader e xmirpc e xmlwriter e xsl 
® Zend OPcache e zip e zlib 
MariaDB Version: 10.4.10 - Port defined for MariaDB: 3306 - Default DBMS - Documentation 
MySQL Version: 8.0.18 - Port defined for MySQL: 3308 - Documentation 
Tools Your Projects Your Aliases Your VirtualHost 
& phpinfo() No projects yet. Ly adminer Lg localhost 
To create a new one, just create a directory in 
& phpmyadmin wee La phpmyadmin 
& Add a Virtual Host La phpsysinfo 
Wampserver Forum 


Figura 5.4: Página inicial do Wamp 


Caso a versão do PHP não esteja na versão 7.4, você pode alterá-la 
sem nenhum problema. Para isso, clique no ícone do Wamp em sua 
barra de tarefas, em seguida, acesse o menu PHP > Version (Versão) 
e selecione a versão 7.2, conforme mostra a imagem a seguir: 






Made in France by Otomatic 
Yit Localhost 

phpMyAdmin 4.9.2 

ES Adminer 47.5 

Your VirtualHosts + 
www directory 













Q 






Version dd. 5.6.40 
4] PHP settings 
34] PHP extensions + 
E php.ini 
E PHP error log 
PHP documentation 














Start All Services 
Stop All Services 
Restart All Services 






Figura 5.5: Alterando a versao do PHP 


Feito isso, automaticamente o Wamp reiniciará todos os serviços 
para que a alteração tenha efeito. Para verificar se o PHP está 
corretamente configurado, na página inicial do Wamp, no canto 
inferior esquerdo em Tools existe uma opção chamada phpinfo() . 
Basta clicar nela, que uma página semelhante à mostrada a seguir 
deverá ser exibida, contendo as informações do PHP: 








cscript /nologo configure.js "-enable-snapshot-build” "-enable-debug-pack” "—with-pdo-oci=c:\php-snap- 
build\deps_aux\oracle\x64\instantclient_12_1\sdk,shared” "-with-oci8-12c=c:\php-snap-build\deps_aux\oracle 
\x64\instantclient_12_1\sdk,shared” "—enable-object-out-dir=../obj/" "—enable-com-dotnet=shared” "—without- 
analyzer” "—with-pgo” 























Registered PHP Streams php, file, glob, data, http, ftp, zip, compress.zlib, compress.bzip2, https, ftps, phar 
Registered Stream Socket Transports tcp, udp, ssl, tls, tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3 


Registered Stream Filters converticonv*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert*, consumed, dechunk, zlib.*, 
bzip2.* 


Figura 5.6: Informações do PHP no Wamp 














5.3 Instalações e configurações adicionais 


O nosso ambiente está pronto para ser utilizado de maneira básica, 
sem frameworks ou URL amigáveis. Mas como vamos trabalhar 
com o Mezzio, precisamos realizar algumas instalações e 
configurações adicionais. 


Habilitando ModRewrite ou RewriteModule no Linux 


O ModRewrite OU RewriteModule é um módulo do servidor Apache que 
é necessário para trabalhar com reescrita de URL, as famosas URL 
amigáveis. 


Para habilitar o módulo em sistemas Linux, basta executar os 
comandos a seguir: 


sudo a2enmod rewrite 
sudo service apache2 restart 


E pronto! O primeiro comando habilita o módulo no servidor Apache, 
e o segundo reinicia o servidor para que a configuração tenha efeito. 


Habilitando ModRewrite ou RewriteModule no Windows 


Para você que utiliza o Windows, habilitar o Modrewrite no Wamp 
também é bastante simples e não precisa digitar nada. Clique no 
icone do Wamp em sua barra de tarefas, vá até a opção apache > 
Apache modules €, por fim, selecione a opção rewrite module (CaSO não 
esteja com o icone verde ao lado) conforme mostra a imagem a 
seguir: 


proxy_module 
proxy_scgi_module 
proxy_uwsgi_module 
proxy_wstunnel_module 
ratelimit_module 
reflector_module 
remoteip_module 


reqtimeout_module 











request_module 


Version > 
> 


x Service administration 'wampapache' 
sed_module 
ES Apache modules » . À 
session cookie module 
Alias directories » 
A httpd.conf 
|A httpd-vhosts.conf 
2 Apache error log 


session crypto module 
session dbd module 
session module 


x“ setenvif module 





|A Apache access log E 
slotmem plain module 





ia Apache documentation 
slotmem_shm_module 


encache dhm module 
v 


Figura 5.7: Habilitando Rewrite Module no Wamp 


Após esse passo, o Wamp deverá ser reinicializado 
automaticamente para que as alterações tenham efeito. 


Se tudo ocorreu bem, o ícone do Wamp deverá ficar verde 
novamente indicando que o serviço está funcionando normalmente. 


Instalando SGDB (Sistema de Gerenciamento de Banco de 
Dados) no Linux 


Vamos utilizar um SGDB para facilitar o gerenciamento do nosso 
banco de dados, pois por linha de comando seria mais complexo e 
demandaria mais tempo. 





O quE É SGDB (SISTEMA DE GERENCIAMENTO DE BANCO DE 
DADOS) 


Como o próprio nome sugere, é um sistema de gerenciamento 
de banco de dados ou uma aplicação/software que é 
responsável por facilitar o gerenciamento de um banco de 
dados, seja para executar consultas, criar tabelas, inserir dados 
etc. 





Se você utiliza o Linux então será necessário fazer a instalação de 
um SGDB. Neste livro, vamos utilizar o MySQL Workbench. Para 
fazer a instalação, basta executar os comandos a seguir: 


sudo apt-get update 
sudo apt-get install mysql-workbench 


Após o término da instalação, basta executar o comando a seguir 
para executar o programa: 


mysql-workbench 


Se a execução do programa foi bem-sucedida, a janela do programa 
deverá ser exibida com sucesso. 


Instalando SGDB no Windows 


Se você utiliza o Windows, com a instalação do Wamp Server, você 
já terá instalado o PHPMyAdmin e para usá-lo basta abrir o seu 
navegador e digitar http://localhost/phpmyadmin/ e a página exibida 
deverá ser semelhante à imagem mostrada a seguir: 


phpMyAdmin 
Bemvindo ao phpMyAdmin 


Lingua - Language 


Portugués - Portuguese s 


Entrada ej) 


Utilizador : 
| roof] 
Palavra-passe: 
Server Choice: 
MySQL e 


Executar 


Figura 5.8: Página de login do PHPMyAdmin 


Note que o campo utilizado mostrado na imagem possui como nome 
root , que é o usuário padrão para o gerenciamento do banco de 
dados. Ao clicar no botão Executar , você será redirecionado para a 


pagina inicial para fazer o gerenciamento de seus bancos de dados, 
conforme mostra a imagem a seguir: 


phpMyAdmin 


aaj o ¿q Base de Dados E SQL & Estado 2: Contas de utilizador =} Exportar |+} Importar 4” Configurações ll. Replicação v Mais 
9 oe 
Servidor atual 
MySQL Y SSeS = e Dase de 
Recente Favoritos & Alterar a palavra-passe Servidor: MySQL (127.0.0.1 via TCP/IP) 
e an x: fe e Tipo de servidor: MySQL 
Now E Ordenação de caracteres da ligação ao servidor @: | utf8mb4_unicode_ci v + Conexão com o senidor: SSL não está sendo usado $) 
Y information_schema + Versão do servidor: 8.0.18 - MySQL Community Server - 
D mysql = Sib 
+ rformance schema “onfiauracões de aspecto + Versão do protocolo: 10 
de Ei An me selena SÃO AE E nto e Utilizador: root@localhost 
E y + Conjunto de caracteres do servidor: UTF-8 Unicode 
& Língua - Language @ | Portugués - Portuguese { (utfêmb4) 


4) Tema: | pmahomme |v 


e Tamanho da fonte: | 82% |» 
e Apache/2.4.41 (Win64) PHP/7.4.0 


& Mais definições . Versão do cliente de base de dados: libmysql - mysqlnd 


+ Extensão de PHP: mysqli @ curl @ mbstring © 
e versão do PHP: 7.4.0 


+ Informação da versão: 4.9.2 

e Documentação 

+ Página Oficial do phpMyAdmin 
e Contributo 

e Obter suporte 

e Lista de alterações 

e Licença 


Figura 5.9: Página de login do PHPMyAdmin 


Caso você não goste de utilizar o PHPMyAdmin ou prefira instalar o 
MySQL Workbench, você pode fazer isso acessando o link 
https://dev.mysql.com/downloads/workbench/. A instalação é bem 
simples como qualquer outra instalação no Windows. 


Instalando o Composer no Linux 


O Composer nada mais é que um gerenciador de pacotes para PHP. 
Com ele, podemos baixar diversas dependências para serem 
utilizadas em nossos projetos. Para saber mais sobre esse 
gerenciador de pacotes acesse: https://getcomposer.org/. 


Para instalar o Composer, execute o comando a seguir: 


sudo php -r "copy('https://getcomposer.org/installer', '/tmp/composer- 
setup.php');" 


O comando anterior baixará o instalador do Composer no diretório 
/tmp . O próximo passo é verificarmos se a assinatura pública do 
arquivo baixado corresponde à assinatura pública no site do 
Composer. Para isso, execute o comando: 


sudo php -r "if (hash file('SHA384', '/tmp/composer-setup.php') === 
'544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdfdd586475ca9813a85 
8088ffbc1f233e9b180f061') { echo ‘Installer verified'; } else { echo 
"Installer corrupt'; unlink('/tmp/composer-setup.php'); } echo PHP_EOL; 


Um ponto importante a ser levado em consideração é quanto ao 
hash que está presente no comando anterior. Ele é obtido no site 
oficial do Composer https://getcomposer.org/download/. Você pode 
simplesmente copiar e colar o comando que está presente no site, 

que funcionará sem problemas. 


Se tudo ocorreu bem você deverá receber a mensagem Installer 
Verified e já podemos seguir em frente. 


O próximo passo é instalar o Composer para uso global, ou seja, 
sem a necessidade de repetir os passos para cada projeto novo. 
Para fazer isso, execute o comando a seguir: 


sudo php /tmp/composer-setup.php --install-dir=/usr/local/bin -- 
filename=composer 


Se tudo ocorreu bem, seu composer foi instalado com sucesso e 
podemos verificar a versão da instalação executando o comando a 
seguir: 


composer - -version 


Até o momento da escrita deste livro o Composer está na versão 
1.9.3. Após executar o comando anterior, o Composer deverá 
retornar uma mensagem informando a versão instalada em sua 
máquina. Com isso, ele está pronto para uso em sua máquina. 


Instalando o Composer no Windows 


Para realizar a instalação, acesse o site 
https://getcomposer.org/doc/00-intro.md#installation-windows/ e 
baixe o arquivo do Composer mais recente. Feito o download, basta 
clicar duas vezes em cima do arquivo baixado e seguir o processo 
de instalação como qualquer outro programa. Após a conclusão, 
abra o CMD ou o Windows Power Shell e execute o comando a 
seguir: 


composer - -version 


Se o resultado exibido na tela for semelhante ao mostrado a seguir, 
a instalação do Composer foi realizada com sucesso: 


EX Windows PowerShell 


5 


rs, Jhones> 





Figura 5.10: Conferindo a versao do Composer no Windows 
Conclusao 


Com isso, finalizamos a preparação do nosso ambiente de 
aprendizagem que será utilizado neste livro. Caso tenha ocorrido 
algum erro durante o processo de configuração do seu ambiente, 
revise os passos e tente novamente. Se mesmo assim não 
conseguir, entre em contato em um dos canais mencionados no 
começo do livro que ficarei feliz em poder ajudar. É muito importante 
que seu ambiente esteja totalmente configurado e funcionando 
corretamente antes de prosseguir para o próximo capítulo. 


CAPITULO 6 
Clonagem e configuração do Mezzio 


Finalmente vamos começar nossa jornada rumo ao conhecimento 
do Mezzio e suas funcionalidades. Uma das principais 
funcionalidades do Mezzio é trabalhar com middlewares que 
facilitam o desenvolvimento da aplicação. Podemos ter diversos 
middlewares em nossa aplicação. 


A maior utilização do Mezzio é para o desenvolvimento de APIs e 
aplicações minimalistas. Neste livro, vamos desenvolver uma API de 
comunicação entre usuários, em que um usuário enviará uma 
mensagem e um outro usuário vai responder a essa mensagem, 
bem semelhante a uma API de chamados. 


Agora, vamos seguir com a instalação do Mezzio. O primeiro passo 
é clonar o projeto em nosso ambiente de desenvolvimento. Acesse 
o site https://docs.mezzio.dev/mezzio/ para fazer o clone do Mezzio. 


Vamos clonar o projeto que já contém o esqueleto básico para 
trabalhar, para isso execute o comando a seguir em seu terminal: 


composer create-project mezzio/mezzio-skeleton /var/www/projeto-mezzio 


Veja que o nome do projeto que estou criando é projeto-mezzio, mas 
você pode colocar um nome de sua escolha. O nosso projeto será 
criado dentro do diretório /var/ww , que é o diretório padrão utilizado 
pelo Apache em ambiente Linux. Caso você utilize o Windows, o 
diretório padrão do WAMP é O c:\wamp64\www\ . 


IMPORTANTE 


Em muitos casos precisamos conceder permissão ao diretório 
/var/www para que possamos criar arquivos e diretórios dentro 


dele, isso porque, após a instalação do Apache o diretório 
/var/www é criado com permissões restritas. Para resolvermos o 
problema, você pode utilizar o comando chown -R nome-do-seu- 
usuario /var/www OU O Comando chmod -R 777 /var/www . 





Quando o processo de criação for iniciado, o Mezzio fará uma série 
de perguntas sobre o que você deseja instalar. 


A primeira pergunta é sobre o tipo de instalação que desejamos. A 
imagem a seguir mostra essa etapa: 


- Installing ( ): Downloading ( 


> MezzioInstaller\OptionalPackages: : install 


] Minimal (no default middleware, templates, or assets; configuration only) 
] Flat (flat source code structure; default selection) 

] Modular (modular source code structure; recommended) 

Make your selection 





[ 
[ 
[ 
1 


Figura 6.1: Selecione o tipo de instalação desejável 
Como você pode ver, o Mezzio nos fornece três opções: 


1. Instalação mínima, que só terá a configuração e nada mais, ou 
seja, não conterá middleware , templates OU assets. 

2. Instalação que contém a estrutura do código, essa é a opção 
padrão definida pelo Mezzio. 

3. Instalação modular, que contém a estrutura modular do código, 
essa é a opção recomendada. 


Vamos selecionar a opção 3 porque ela já fornecerá uma estrutura 
modular, isso significa que podemos ter diversos módulos dentro da 
nossa API. Por exemplo, por padrão, o módulo padrão é o app, mas 
podemos ter também outros módulos como: Livro, Jhones etc., 
então tecle ENTER para prosseguir com a instalação. 


A próxima pergunta é sobre qual contêiner de injeção de 
dependência desejamos instalar. 
O QUE É CONTÉINER DE INJEÇÃO DE DEPENDÊNCIA? 


Um contêiner de injeção de dependências realiza o controle das 
instâncias das classes, informando exatamente quando um 
objeto deverá ser criado. 


Aura.Di 
Pimple 


Auryn 
Symfony DI Container 
PHP-DI 
Make your selection or type a composer package name and version 


| 
| 
] laminas-servicemanager 
| 
| 
| 





Figura 6.2: Selecione o tipo de contêiner de injeção de dependência 


Será exibida uma lista de opções de contêineres de injeção de 
dependência, com as seguintes opções: 


1. Aura.Di - é um contéiner de injeção de dependência serializável 
com injeção de construtor e setter , reconhecimento de 
interface, herança de configuração e muito mais. 

2. Pimple - é um pequeno contéiner de injeção de dependência 
para PHP baseado no Symfony. 

3. laminas-servicemanager - baseado no Laminas, o padrão de 
design do Service Locator é implementado pelo componente 
Laminas\ServiceManager . O Service Locator é um localizador de 
serviços/objetos, encarregado de recuperar outros objetos. 

4. Auryn - é um injetor de dependência recursivo. 


5. Symfony DI Container - permite padronizar e centralizar a maneira 
como os objetos são construídos em sua aplicação. 

6. pHP-DI - é um contêiner de injeção de dependência que 
pretende ser prático e poderoso. 


Todas as opções listadas anteriormente são contêineres de injeção 
de dependência. Selecione a opção 3 - laminas-servicemanager , pois 
é bem simples de trabalhar. Em seguida, tecle enter para 
prosseguir com a instalação. 


A próxima pergunta que o Mezzio fara é sobre qual sistema de rotas 
desejamos instalar, conforme mostra a imagem a seguir: 


[1] Aura.Router 
[2] FastRoute 
[3] 


laminas-router 
Make your selection or type a composer package name and version 





Figura 6.3: Selecionando o tipo de sistema de rotas 


O QUE É SISTEMA DE ROTAS? 


Nada mais é que o modo como as rotas são definidas e 


utilizadas dentro da sua aplicação. É através das rotas definidas 
que conseguiremos utilizar determinados recursos da nossa API. 





Será exibida uma lista de opções de sistemas de rotas com as 
seguintes opções: 


1. Aura.Router - roteamento Web poderoso e flexível para 
requisições da psr-7. 

2. FastRoute - esta biblioteca fornece uma implementação rápida 
baseada em expressões regulares. 

3. laminas-router - O roteamento funciona de acordo com as 
solicitações e respostas do laminas-http . 


Temos três opções de sistema de rotas para selecionarmos. Vamos 

selecionar a opção 1, Aura.Router . Tecle ENTER para prosseguir com 
a instalação. Estamos escolhendo essa opção porque O aura.Router 

é bem simples, fácil, prático e flexível. 


A próxima pergunta é sobre o tipo de template de visualização que 
desejamos ou não instalar conforme mostra a imagem a seguir: 


] Plates 
] Twig 


] None of the above 


[ 

[ 

[3] laminas-view 

[ 

Make your selection or type a composer package name and version : a] 





Figura 6.4: Selecionando o tipo de template de visualização 


O QUE É TEMPLATE DE VISUALIZAÇÃO? 


É o modo como as informações serão apresentadas para os 


usuários, são as Views ou páginas de exibição, como muitos 
preferem chamar. 





Será exibida uma lista de opções, são elas: 


1. Plates - é um sistema de template PHP nativo que é rápido, 
fácil de usar e de estender. 

2. Twig - é uma linguagem modelo para PHP que utiliza uma 
sintaxe semelhante às linguagens de modelos Django e Jinja 
que inspiraram o Twig. 

3. laminas-view installs laminas-servicemanager - fornece a camada 
view do sistema Laminas MVC. É um sistema de múltiplas 
camadas que permite uma variedade de mecanismos para 
extensão, substituição e muito mais. N. None of the above - 
nenhuma das opções, caso não deseje instalar nenhum deles. 


Vamos selecionar a opção 3, laminas-view . Aqui estamos 
selecionando essa opção porque o código fica mais legível e, além 


disso, é bem simples. Tecle enter para prosseguir com a instalação. 


A próxima e última pergunta que o Mezzio fará é sobre qual o tipo 
de manipulador de erros desejamos utilizar. 


O QUE É MANIPULADOR DE ERROS OU ERROR HANDLER? 


É o modo como os erros da aplicação serão tratados e lançados 
para o usuário. 





Veja a seguir a imagem contendo as opções disponíveis para 
selecionarmos: 


[1] Whoops 


[n] None of the above 
Make your selection or type a composer package name and version 





Figura 6.5: Selecionando o tipo de manipulador de erros 


A imagem anterior disponibiliza para escolha uma lista contendo as 
seguintes opções: 


1. Whoops - é um manipulador de erros para PHP que fornece 
uma interface de erro que ajuda nos ajuda a depurar nossos 
projetos Web. 


n. None of the above - nenhuma das opções, caso você não deseje 
instalar um manipulador de erros. 


Como você pode ver na imagem anterior, há apenas duas opções, 
nós selecionamos a opção 1 que corresponde ao whoops . Tecle 
ENTER para prosseguir com a instalação. Estamos selecionando 
essa opção, porque o Whoops é um excelente manipulador de erros 
que nos ajuda a identificar os erros de forma eficaz e bem intuitiva. 


Após essa etapa, o Mezzio começará a baixar uma série de 
pacotes. Ao término da instalação, você terá uma saída semelhante 


a mostrada na imagem a seguir: 


laminas/laminas-servicemanager suggests installing ocramius/p 
symfony/service-contracts suggests installing symfony/service 
symfony/console suggests installing symfony/event-dispatcher 
symfony/console suggests installing symfony/lock 
symfony/console suggests installing symfony/process 
mezzio/mezzio suggests installing lLaminas/ laminas -auradi-conf 
mezzio/mezzio suggests installing laminas/laminas-pimple-conf 
laminas/laminas-code suggests installing doctrine/annotations 
sebastian/global-state suggests installing ext-uopz (*) 
phpunit/php-code-coverage suggests installing ext-xdebug (^2. 
phpunit/phpunit suggests installing phpunit/php-invoker (72.0 


phpunit/phpunit suggests installing ext-xdebug (*) 

filp/whoops suggests installing symfony/var-dumper (Pretty pr 
filp/whoops suggests installing whoops/soap (Formats errors a 
Package container-interop/container-interop is abandoned, you 


Generating version class... 
...done generating version class 
> Laminas-development-mode enable 
You are now in atest A 
$ 





Figura 6.6: Instalacáo do Mezzio Concluída 


Pronto. O microframework realizou a instalação de alguns pacotes 
que sáo necessários para o seu funcionamento, é o que chamamos 
de core. Com o Mezzio instalado em nosso ambiente já podemos 
verificar se ele está funcionando corretamente. É o que veremos na 
próxima secáo. 


6.1 Hello Mezzio 


Para verificar se o microframework esta funcionando corretamente, 
basta executar o comando a seguir em seu terminal, na raiz do 
projeto: 


composer serve 


Esse comando fará com que o servidor embutido dentro do PHP 
seja executado e gere um endereço de para acessar o projeto por 
meio do navegador. O endereço gerado você pode conferir na linha: 
php -S 0.0.0.0:8080 -t public/ Conforme mostra a imagem a seguir: 


> php -S 0.0.0.0:8080 -t public/ 


[Tue Feb 11 11:11:33 2020] PHP 7.4.2 Development Server (http://0.0.0.0:8080) started 





Figura 6.7: Iniciando o Mezzio com Composer Serve 


Perceba que o endereço que o comando gerou foi o e.e.e.e:sese , 
que você deverá informar em seu navegador. Dessa forma, uma 
página semelhante à imagem a seguir deverá ser exibida: 


e C ù ®© localhost soo Y Im O: 





Laminas Mezzio E 


Welcome to mezzio 


Congratulations! You have successfully installed the mezzio skeleton application. This skeleton can serve as a simple starting point for you to begin 
building your application. 


Mezzio builds on laminas-stratigility to provide a minimalist PSR-7 middleware framework for PHP. 


5 Agile & Lean 


Mezzio is fast, small and perfect for rapid 
application development, prototyping and api's. 
You decide how you extend it and choose the 
best packages from major framework or 


standalone projects. 


2 HTTP Messages 


HTTP messages are the foundation of web 
development. Web browsers and HTTP clients 
such as cURL create HTTP request messages 
that are sent to a web server, which provides an 
HTTP response message. Server-side code 
receives an HTTP request message, and returns 
an HTTP response message. 


Figura 6.8: Página inicial do Mezzio 


O Middleware 


Middleware is code that exists between the 
request and response, and which can take the 
incoming request, perform actions based on it, 
and either complete the response or pass 
delegation on to the next middleware in the 
queue. Your application is easily extended with 
custom middleware created by yourself or others. 


Maravilha! O microframework esta executando sem a necessidade 
de criar um VHOST dentro do nosso servidor Apache. Na próxima 
seção vamos criar um VHOST no Linux para acessarmos o projeto 
de forma menos trabalhosa. 


O QUE É UM VHOST ou VIRTUAL HOST? 


É um arquivo de configuração que possui códigos específicos 


para o funcionamento de um projeto Web de forma mais 
elegante e funcional. Essa configuração permite acessarmos 
nosso projeto por meio de um nome. 





6.2 Configurando o Mezzio com VHOST no Linux 


Vimos que é possível executar o Mezzio pelo comando composer 
serve , que inicializará o servidor embutido dentro do PHP, até aí 
nenhum problema. Mas imagine você ter que digitar o IP e a porta 
no navegador para ter acesso ao projeto, seria cansativo toda vez 
ter que digitar: 0.0.0.0:8080 , concorda? 


Então, vamos ver agora como configurar o Mezzio para executar 
através de um Virtual Host. Esse processo fará com que o 
microframework seja executado como se fosse um site através de 
um endereço. 


Criar um VHOST para o nosso projeto no Linux não é una tarefa 
difícil, mas é trabalhosa. Siga os passos descritos adiante, que tudo 
ocorrerá bem, combinado? 


Primeiramente precisamos entrar no diretório sites-available dentro 
do nosso servidor Apache, com o comando: 


cd /etc/apache2/sites-available 


Uma vez dentro do diretório, vamos criar o nosso arquivo de 
configuração através do arquivo já existente, com o comando: 


sudo cp 000-default.conf projeto-mezzio.conf 


Esse comando realiza uma cópia do arquivo ese-default.conf COMO 
nome projeto-mezzio.conf . Vamos agora ver o conteúdo desse 
arquivo para que possamos alterá-lo. Estou utilizando o Vim para 
abrir o arquivo, mas você pode usar qualquer outro editor de texto 
de sua preferência. 


Para abrir o arquivo que criamos, execute o comando: 


vim projeto-mezzio.conf 


Seu arquivo deve se parecer com a imagem a seguir: 


n webmaster@LocaLlhost 
t /var/www 


Log ${APACHE LOG DIR}/ . Log 
| S(APACHE LOG DIR}/access.log combined 





“livro-zend-expressive.conf" 31L, 


Figura 6.9: Conteúdo padrão do arquivo de configuração 


Nós faremos algumas alterações nesse arquivo para que o nosso 
projeto possa funcionar corretamente. Primeiramente, vamos ao 
código que colocaremos em nosso arquivo de configuração: 


<VirtualHost *:80> 
ServerName projeto-mezzio.local 
DocumentRoot /var/www/projeto-mezzio/public 
CustomLog /var/log/apache2/access.log common 
ErrorLog /var/log/apache2/error.log 


<Directory /var/www/projeto-mezzio/public> 
<IfModule mod rewrite.c> 
RewriteEngine On 
RewriteCond %{REQUEST FILENAME} !-f 
RewriteRule ^ index.php [L] 
</IfModule> 
</Directory> 
</VirtualHost> 


Nesse código, estamos informando que O ServerName É projeto- 
mezzio. local, esse nome é o que vamos digitar na barra de endereço 
do navegador. Um outro ponto bem importante é o DocumentRoot , que 
deve conter o caminho completo até a pasta public do nosso 
projeto. 


Perceba também que temos duas configurações de LOGs: 
CustomLog @ ErrorLog , ambas apontam para a pasta de LOG do 
proprio Apache, que contera tanto LOGs de tentativa de acesso, 
quanto LOGs de erro da aplicação. 


Substitua o código que esta atualmente dentro do arquivo 
/etc/apache2/sites-available/projeto-mezzio.conf pelo código anterior. 


Salve o arquivo e, em seguida, vamos habilitar a configuração que 
acabamos de criar. Para isso, execute o comando a seguir: 


a2ensite projeto-mezzio.conf 


Agora basta recarregarmos o serviço do Apache para que a nova 
configuração já esteja disponível para uso: 


service apache2 reload 


Se nenhum erro ocorreu até aqui, entao parabéns! Acabou? Ainda 
nao, meu caro amigo, falta apenas definirmos o host que vamos 
acessar ao digitarmos na barra de navegação do navegador. Sabe 
aquele nome que definimos dentro do nosso arquivo de 
configuração em serverName ? É exatamente o mesmo nome que 
vamos colocar no nosso arquivo hosts . Então, abra o arquivo no 
seu editor de texto: 


vim /etc/hosts 


Coloque o código a seguir ao final de seu arquivo hosts : 


127.0.0.1 projeto-mezzio.local 


Pronto, salve seu arquivo, abra o seu navegador e digite 
http://projeto-mezzio.local/. Se tudo ocorreu bem, a página inicial do 
Mezzio será exibida para você. Caso tenha ocorrido algum erro, 
revise os passos com calma e atenção que tudo vai dar certo. 


6.3 Configurando VHOST no Wamp Server 


Criar um VHOST no Wamp Server hoje é mais simples e não requer 
muito trabalho. Primeiramente, inicie o seu Wamp Server caso ainda 
não esteja em execução, e depois que o icone do Wamp Server 
estiver verde, abra seu navegador e digite http://localhost . À 
página inicial do Wamp Server deve ser exibida conforme mostra a 
imagem a seguir: 


O, 











WampServer 
Version 3.2.0 - 64bit classic v 
Server Configuration 
Apache Version: 2.4.41 - Documentation 
Server Software: Apache/2.4.41 (Win64) PHP/7.4.0 - Port defined for Apache: 80 
PHP Version: 7.4.0 - Documentation 
Loaded Extensions: * apache2handler e bemath e bz2 e calendar 
® com dotnet e Core e ctype e curl 
e date e dom e exif e fileinfo 
e filter e gd e gettext e gmp 
e hash e iconv e imap e intl 
e json e idap e libxml e mbstring 
e mysqli e mysglnd ® openssl e pcre 
e PDO e pdo mysql e pdo sqlite e Phar 
e readline e Reflection ® session ® SimpleXML 
e soap e sockets e SPL e sqlite3 
e standard e tokenizer e xdebug e xml 
e xmlreader e xmirpc e xmiwriter e xsl 
e Zend OPcache e zip e zlib 
MariaDB Version: 10.4.10 - Port defined for MariaDB: 3306 - Default DBMS - Documentation 
MySQL Version: 8.0.18 - Port defined for MySQL: 3308 - Documentation 
Tools Your Projects Your Aliases Your VirtualHost 
& phpinfo() No projects yet. Ly adminer Lg localhost 
To create a new one, just create a directory in 
& phpmyadmin ad y phpmyadmin 
& Add a Virtual Host La phpsysinfo 
Wampserver Forum 


Figura 6.10: Página inicial do Wamp 





Na seção Tools OU Ferramentas , localize no canto inferior esquerdo o 
menu Add a Virtual Host . Ao clicar nele, você será redirecionado 
para uma nova tela, onde vocé informará os dados conforme mostra 
a imagem a seguir: 


Add a VirtualHost - Back to homepage 


+ Version 3.2.0 -64bit [english +] 


Apache Virtual Hosts PEA NS a 





VirtualHost already defined: 


ServerName : localhost - Directory : c:/wamp64/www 























Tf you want to use a "Listen port" other than the default one, you must add a Listen Port to Apache by Right-Click Tools RHEE 





(GB you want to use VirtualHost by IP: FERIAS 


BSF Optional 


Start the creation of the VirtualHost (May take a while...) 











Figura 6.11: Criando VHOST no Wamp Server 


No primeiro campo, devemos informar o nome do host, ou seja, O 
nome que vamos digitar para acessar a aplicação. Vamos utilizar o 
nome projeto-mezzio. local . No segundo campo, devemos informar o 
caminho completo até o diretório public do projeto. No caso seria 
algo semelhante a C:/wamp/www/projeto-mezzio/public . O terceiro 
campo não é obrigatório, mas se desejar preenchê-lo, você deverá 
informar o IP no qual o projeto poderá ser acessado ao digitar na 
barra de endereço do navegador. 


Após ter preenchido os campos obrigatórios, clique no botão para 
criar o VHOST. Você deverá visualizar uma página semelhante a 
imagem a seguir: 


Add a VirtualHost - Back to homepage 











+ Version 3.2.0 - 64bit | english Y 








Messages from the console to update DNS: 





Restart DNS 


Figura 6.12: VHOST criado com sucesso no Wamp Server 


O próximo passo é reiniciar o servico de DNS do Wamp Server. No 
menu Tools , selecione a opção Restart DNS. 


Pronto, basta aguardar o ícone do Wamp Server ficar verde 
novamente. Abra o seu navegador e digite http://projeto- 

mezzio. local, se tudo ocorreu bem, a página inicial do Mezzio deverá 
ser exibida. 


Parabéns, o Mezzio está funcionando através de um VHOST, e com 
isso podemos seguir em frente. 


6.4 Bug Fix Apache ServerSignature 


Se você conseguiu executar com sucesso o Mezzio em seu 
ambiente sem ocorrer nenhum erro, então você poderá pular esta 
seção. Caso contrário, os passos descritos a seguir vão ajudá-lo a 
efetuar a correção. 


Se após a configuração do Mezzio em seu ambiente, você está 
obtendo erro see ao executar o Mezzio, será necessário realizar um 
pequeno ajuste na configuração de seu Apache. O erro acontece no 
cabeçalho SERVER SIGNATURE que é enviado pelo Apache. 
Internamente, o Mezzio realiza uma validação do valor enviado 


nesse cabeçalho, e se ele não for válido ocorre esse erro. Para 
solucioná-lo siga um dos passos a seguir. 


Windows 


Para ambiente Windows estamos utilizando o Wamp, então basta 
abrir o arquivo C: \wamp\bin\apache\apache2.4.41\conf\httpd.conf e 
localizar o seguinte trecho de código: 


ServerSignature On 


Em seguida, altere o valor on para off: 


ServerSignature Off 


Salve o arquivo e reinicie seu Wamp. Se tudo ocorreu bem ele ficou 
verde novamente e você já poderá testar o Mezzio. Se dessa vez 
não ocorreu erro 500 e apresentou a página inicial corretamente, o 
problema foi solucionado. 


Linux 


Se você utiliza o Linux baseado em uma distro Debian, basta abrir o 
arquivo /etc/apache2/conf-enabled/security.conf € localizar o seguinte 
trecho de código: 


ServerSignature On 
Em seguida, altere o valor on para off: 


ServerSignature Off 


Salve o arquivo e reinicie o serviço do Apache com o comando a 
seguir: 


service apache2 restart 


Você já poderá testar o Mezzio. Se dessa vez não ocorreu erro 500 
e a página inicial apareceu corretamente, o problema foi 
solucionado. 


6.5 Conhecendo a estrutura do Mezzio 


Agora que já fizemos as configurações necessárias, podemos 
conhecer a estrutura do Mezzio e seus principais arquivos. Abra o 
nosso projeto projeto-mezzio com a sua IDE e vamos analisar a 
estrutura do microframework. 


Y By projeto-mezzio 


a -gitignore 

va COMpoOserjson 

ya composer.lock 
ía COPYRIGHT.md 
img LICENSE.md 

+ Phpcs.xml.dist 


A phpunit.xml.dist 
¿E README.md 





Figura 6.13: Estrutura do Mezzio 


Como podemos ver na imagem anterior, a estrutura de diretorios do 
Mezzio é relativamente pequena e simples. Mas o que significa cada 


um desses diretórios? É isso que veremos a seguir: 


bin - esse diretório contém arquivos executáveis via terminal. 
Por exemplo, se você expandir esse diretório, você verá um 
arquivo chamado clear-config-cache.php , responsável por limpar 
o cache de configuração do microframework. Para utilizá-lo, 
basta você entrar no diretório raiz do projeto e executar o 
comando php bin/clear-config-cache.php . Você poderá criar 
qualquer executável dentro desse diretório. 


config - esse diretório é muito importante para o funcionamento 
do Mezzio, porque ele contém arquivos de configuração do 
microframework. Arquivos de configuração de banco de dados 
e rotas também entram nesse diretório. 


config/autoload - contém arquivos de configuração que são 
carregados automaticamente com o microframework, como as 
configurações de carregamentos de middlewares , helpers , 
factories etc. 


config/autoload/dependencies.global.php - é um arquivo que 
possui algumas configurações de modo global que são 
utilizadas por todo o microframework, como o cache de 
configurações, por exemplo. 


config/autoload/development.local.php - esse arquivo 
contém configurações que são utilizadas apenas em ambiente 
de desenvolvimento, como manipuladores de erros, por 
exemplo. Outro ponto importante é que esse arquivo não deve 
ser versionado. 


config/autoload/development.local.php.dist - é o mesmo 
arquivo que o anterior, porém com a extensão .dist no final. 
Essa extensão informa que o arquivo é um modelo e pode ser 
versionado, assim o desenvolvedor que atualizar o projeto deve 
copiar esse arquivo e retirar a extensão .dist. 


config/autoload/local.php.dist - também é um arquivo de 
modelo e para usa-lo basta renomea-lo removendo a extensao 
.dist . Nele, vocé pode utilizar dados locais como usuarios e 
senhas. 


config/autoload/mezzio.global.php - é um arquivo de 
configuração global, onde podemos habilitar ou desabilitar o 
cache de configuração de toda a aplicação e ainda definir um 
modelo de template para respostas de erros. 


config/config.php - contém as principais configurações da 
aplicação, realizando o carregamento das demais 
configurações citadas, além de definir o diretório para gravação 
de cache, registrar configurações como tipo de rota, tipo de 
template etc. É um arquivo muito importante para o 
microframework. 


config/container.php - esse é outro arquivo muito importante, 
responsável por carregar todas as configurações através do 
serviço de injeção de dependência. 


config/development.config.php - esse é um arquivo 
responsável por permitir a ativação do modo de 
desenvolvimento, como debug € cache. 


config/development.config.php.dist - é exatamente como o 
arquivo anterior, com a diferença de que possui a extensão 
.dist , OU Seja, é um arquivo que serve como modelo. 


config/pipeline.php - esse arquivo também é muito importante 
e é responsável por realizar a inicialização dos middlewares 
globais da aplicação. 


config/routes.php - esse arquivo é simplesmente responsável 
por conter todas as rotas da aplicação, ou seja, toda vez que for 
necessário criar uma nova rota, é nesse arquivo que vamos 
mexer. É um arquivo extremamente importante, atente-se a ele. 


data - é o diretório responsável por conter arquivos de cache, 
diagramas etc. É nesse diretório que devemos salvar os caches 
da aplicação, como os caches do Doctrine. Veremos na prática 
a utilização desse diretório, não se preocupe. 


public - simplesmente contém o arquivo index.php, que é 
responsável por realizar a inicialização da aplicação. Quando 
chamarmos uma rota da aplicação, esse é o primeiro arquivo a 
ser executado pelo servidor. 


src (source) - esse diretório deverá conter todos os arquivos 
que serão criados para o desenvolvimento da aplicação. 
Arquivos como entidades, repositórios, validators, middlewares, 
deverão estar dentro dele. 


src/App - é o nome do módulo que padrão que o Mezzio criou. 
Dentro dele há um outro diretório chamado src, além de um 
diretório chamado templates , que veremos com mais detalhes 
adiante. 


src/App/src - basicamente é o mesmo funcionamento do 
diretório src principal, e deverá conter todas as classes 
referentes ao módulo. 


src/App/src/Handler - esse diretório funciona como o diretório 
Controller do Laminas MVC e de outros frameworks. O nome 
do diretório é flexível: se desejar chamar de "Action" por 
exemplo, você pode realizar essa alteração sem nenhum 
problema. Nós veremos mais sobre os diretórios que criaremos 
no decorrer deste livro. 


src/App/src/ConfigProvider.php - cada módulo criado deve 
conter esse arquivo, ele é responsável por realizar a 
inicialização de arquivos como services, factories, handlers etc. 
Trabalharemos bastante nesse arquivo no decorrer deste livro. 


src/App/templates - esse diretório é responsável por conter 
todas as views da aplicação, incluindo templates de erros e o 


layout padrão. 


e test - como o próprio nome sugere, é uma pasta que contém os 
testes de unidade e testes funcionais da aplicação. Todo e 
qualquer tipo de teste que for escrito para a aplicação deve ser 
criado dentro dessa pasta, respeitando a hierarquia de 
diretórios contido dentro da pasta src. 


e vendor - esse diretório contém todas as bibliotecas utilizadas 
pela aplicação, ou seja, é um diretório criado pelo Composer 
quando o instalamos, contendo todas as bibliotecas 
necessárias. Se futuramente for necessário realizar a inclusão 
de uma nova biblioteca, o Composer a salvará nesse diretório. 


e composer.json - é um arquivo que o Composer lê para fazer a 
instalação ou atualização de bibliotecas. Basicamente é um 
arquivo no formato JSON contendo alguns pares (chave-valor) 
que o Composer lê, interpreta e executa uma determinada 
ação. Todas as bibliotecas utilizadas pela aplicação deverão 
estar presentes nesse arquivo. 


e composer.lock - sempre que você for realizar a instalação de 
uma nova biblioteca em sua aplicação, o Composer atualizará 
as informações nesse arquivo. Assim, quando outro 
desenvolvedor ou até mesmo você configurar o projeto em 
outro local, as versões exatas das bibliotecas serão instaladas, 
evitando erros ocasionados por bibliotecas ou versões 
diferentes. 


e phpcs.xml.dist - esse é um arquivo de configuração utilizado 
para a padronização de códigos utilizando a PSR-2 (Já 
descontinuada, a nova é a PSR-12). 


e phpunit.xml.dist - arquivo de configuração de testes com o 
PHPUnit, quando for utilizá-lo renomeie para phpunit.xml 


Essa é a estrutura do Mezzio. Como podemos ver, não é uma 
estrutura complexa. Em um primeiro momento, ela pode ser 


confusa, principalmente se esse é o seu primeiro contato com 
framework, mas não se preocupe, porque vamos trabalhar muito 
utilizando essa estrutura e você se adaptará com facilidade. 


Conclusão 


Neste capítulo, vimos como clonar e configurar o Mezzio em nosso 
ambiente de desenvolvimento e ainda conhecemos um pouco de 
sua estrutura. Com isso, estamos aptos a iniciar o desenvolvimento 
do nosso projeto. No próximo capítulo, vamos criar nosso banco de 
dados, que será utilizado pela nossa aplicação e também 
configuraremos o ORM Doctrine para que possamos criar nossas 
entidades e nossos repositórios. Então, siga em frente. :) 


CAPITULO 7 
Configurando o Doctrine ORM e gerando 
entidades 


Antes de prosseguirmos, é necessário que você acesse o link 
https://bit.ly/2SLOIr3 e faça o download do esquema básico do 
banco de dados que será utilizado pela aplicação. Caso você tenha 
algum problema com o link, você poderá baixar o arquivo 

projeto mezzio db.sql diretamente do repositório do projeto no link a 
seguir: https://github.com/jhones/projeto- 
mezzio/tree/master/data/sql/. Não é um banco grande e complexo, 
mas pequeno e simples, que servirá para o nosso projeto de API. 


Após ter efetuado o download do arquivo, importe-o para o banco de 
dados porque vamos utilizá-lo junto para gerarmos as entidades 
mais adiante neste capítulo. 


7.1 Integrando o Doctrine ao Mezzio 


Antes de mais nada, primeiramente vamos clonar o Doctrine em 
nosso projeto utilizando o Composer. Para isso execute o comando 
a seguir na raiz do nosso projeto: projeto-mezzio : 


composer require doctrine/orm 


Se tudo ocorreu bem, vocé deverá ter uma saída semelhante á 
mostrada na imagem a seguir: 


Using version 


- Installing ( ): Downloading ( ) 

- Installing ( ): Downloading ( 
- Installing ( E 0 

- Installing ( ): Downloading ( 
- Installing ( ): Downloading ( 

- Installing ): Downloading ( ) 

- Installing ( ): Downloading ( 


- Installing ( ): Downloading ( ) 

- Installing ( ): Downloading ( ) 

- Installing ): Downloading ( ) 

- Installing ( ): Downloading ( ) 
doctrine/cache suggests installing alcaeus/mongo-php-adapter (Required to use legacy MongoDB driver) 
doctrine/orm suggests installing symfony/yaml (If you want to use YAML Metadata Mapping Driver) 


Generating version class... 
...done generating version class 





Figura 7.1: Clonando o Doctrine ORM 


Após o clone do Doctrine ter sido bem-sucedido, devemos criar um 
arquivo de configuração chamado cli-config.php dentro do diretório 
config Com o seguinte conteúdo: 


<?php 
use Doctrine\ORM\Tools\Console\ConsoleRunner; 
use Doctrine\ORM\EntityManager; 


require _DIR_ . '/../vendor/autoload.php'; 


/** @var \Interop\Container\ContainerInterface $container */ 
$container = require _DIR_ . '/../config/container.php' ; 


/** @var \Doctrine\ORM\EntityManager $em */ 
fem = $container->get (EntityManager: :class); 


return ConsoleRunner: :createHelperSet($em) ; 


O código anterior é responsável por carregar as configurações do 
Doctrine para que possamos utilizá-lo através do terminal. Isso é 
necessário pois mais adiante, neste capítulo, realizaremos a 
geração das entidades com base nas nossas tabelas do banco de 
dados. 


O próximo passo é criarmos o arquivo chamado doctrine.local.php 
dentro do diretório config/autoload com o seguinte conteúdo: 


<?php 


return [ 
‘doctrine’ => [ 
"connection' => [ 


‘orm' => [ 
“auto generate proxy classes' => true, 
“proxy dir' => 'data/cache/Proxy', 
"proxy namespace' => 'Proxy', 
'underscore naming strategy’ => true, 


1, 
'"orm_default' => [ 
'driverClass' => 
Doctrine\DBAL\Driver\PDOMySq1\Driver::class, 
'host' => 'localhost', 
'port' => 3306, 
'user' => 'root', 
'password' => 'root', 
'dbname' => 'projeto_mezzio db', 
'driverOptions' => [ 
\PDO: :MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8"'" 


1, 
1, 


1; 


O arquivo anterior é muito importante porque define as 
configurações de acesso ao banco de dados, além de fazer a 
gravação de proxies , que são uma espécie de cache para agilizar 
as consultas. Perceba que a chave proxy dir, contida dentro da 
chave orm, indica o diretório em que esses caches serão 
armazenados, logo, é necessário criá-lo e conceder permissão de 
escrita. Para isso, execute os comandos a seguir na raiz do seu 
projeto: 


mkdir data/cache 
mkdir data/cache/Proxy 
chmod -R 777 data/ 


Com os comandos anteriores, você criará o diretório cache € Proxy, 
já concedendo permissão 777, ou seja, acesso total para este 
diretório. A chave orm default contém as configurações de acesso 
ao banco de dados que você criou e cujas tabelas importou. No meu 
caso, a configuração contida no código está correta, você deve 
alterá-la para adequar-se de acordo com a sua configuração local. 


MAS AFINAL O QUE É UMA FACTORY? 


Uma Factory ou Fábrica é um padrão de projeto responsável por 


criar objetos sem expor a criação lógica para o cliente, ou seja, 
ele permite criar objetos sem que o cliente saiba como é o 
processo de criação. No Mezzio ele será muito utilizado. 





Por fim, deveremos criar uma Factory para fazer o carregamento 
das configurações do Doctrine no Mezzio e chamá-la no arquivo de 
configuração dependencies.global.php . Primeiramente, vamos criar a 
nossa Factory . Dentro do diretório src que está dentro de app, crie 
os diretórios Doctrine € Factory e, em seguida, uma classe 
chamada DpoctrineormFactory . Nesse momento sua estrutura de 
diretórios deve estar parecida com a imagem a seguir: 


projeto-mezzio 


bin 
config 
data 
public 
src 
App 
¥ src 
¥ Doctrine 





Factory 


Figura 7.2: Estrutura de diretórios e criação da classe DoctrineORMFactory 


Abra a classe DoctrineoRMFactory € insira o conteúdo a seguir dentro 
dela: 


<?php 
declare(strict types=1); 
namespace App\Doctrine\Factory; 


use Doctrinei Common 
Annotations \AnnotationReader, 
Annotations \AnnotationRegistry 
> 
use Doctrine\ORM\{ 
Configuration, 
EntityManager, 


Mapping \UnderscoreNamingStrategy, 
Mapping\Driver\AnnotationDriver 
> 


use PSR\Container\ContainerInterface; 


class DoctrineORMFactory 


{ 
public function _ invoke(ContainerInterface $container): EntityManager 
1 
$config = $container->has('config') ? $container->get('config') : 
[]; 
$proxyDir = (isset($config['doctrine']['connection']['orm'] 
[ 'proxy_dir'])) ? 
$config[ 'doctrine']['connection']['orm']['proxy_dir'] : 
'data/cache/EntityProxy? ; 
$proxyNamespace = (isset($config['doctrine']['connection']['orm'] 
[ 'proxy_namespace'])) ? 
$config[ 'doctrine']['connection']['orm']['proxy_namespace'] : 
"EntityProxy' ; 
$autoGenerateProxyClasses = (isset($config[ ‘doctrine’ ] 
['connection']['orm']['auto generate proxy classes'1)) ? 
$config[ 'doctrine']['connection']['orm'] 
[auto generate proxy classes'] : true; 
$underscoreNamingStrategy = (isset($config['doctrine'] 
['connection']["orm']['underscore naming strategy'])) ? 
$config[ 'doctrine']['connection']['orm'] 
['underscore naming strategy'] : true; 


$doctrine = new Configuration(); 
$doctrine->setProxyDir($proxyDir); 
$doctrine->setProxyNamespace($proxyNamespace) ; 
$doctrine->setAutoGenerateProxyClasses($autoGenerateProxyClasses) ; 
if ($underscoreNamingStrategy) { 

$doctrine->setNamingStrategy(new UnderscoreNamingStrategy()); 


AnnotationRegistry::registerFile(_ DIR_ . 
"/../../../../../vendor/doctrine/orm/1ib/Doctrine/ORM/Mapping/Driver/Doctr 
ineAnnotations.php'); 

$driver = new AnnotationDriver( 

new AnnotationReader(), 


[DIR . ‘/../../../src/Entity' ] 
y 


$doctrine->setMetadataDriverImpl($driver); 


return EntityManager: :create($config[ 'doctrine']['connection'] 
['orm_default'], $doctrine); 


} 
| 


Vamos entender a classe DoctrineormFactory . Ela possui a 
responsabilidade de setar as configurações para o funcionamento 
do Doctrine, definindo o diretório em que as entidades estarão 
inclusas, assim como as configurações para geração de proxy das 
entidades. Perceba ainda que essa classe retorna um objeto 
EntityManager que será utilizado pela nossa aplicação. 


Há três pontos importantes exclusivos do PHP 7: primeiramente, o 
código declare(strict types=1) , que informa que nesse arquivo sera 
utilizado o modo estrito do PHP 7. Isso significa que estamos 
informando ao PHP para ser rigoroso quanto à tipificação de 
parâmetros, retornos etc. Dessa forma, também podemos definir o 
tipo de retorno dos métodos e dos parâmetros. 


Perceba que estamos utilizando o método _ invoke. Todas as 
Factories que criarmos deverão ter obrigatoriamente esse método 
mágico. Ele é chamado quando um determinado script fizer uma 
tentativa de chamada a um objeto como uma função. Você pode 
conhecer mais sobre o método _ invoke no link da documentação 
oficial: 
http://php.net/manual/pt_BR/language.oop5.magic.php#object.invok 
el. 


O segundo ponto a ser considerado é a declaração use . Perceba 
que temos dois blocos de use com o Doctrine, sendo eles: 


use Doctrine\Common\{ 
Annotations\AnnotationReader, 
Annotations \AnnotationRegistry 


y; 


use Doctrine\ORM\{ 
Configuration, 
EntityManager, 
Mapping \UnderscoreNamingStrategy, 
Mapping\Driver\AnnotationDriver 


}; 


Agrupamos os namespaces que estão dentro do grupo 
Doctrine\Common € do grupo Doctrine\orRM , e esse agrupamento so se 
tornou possível com o PHP 7. E o melhor: está completamente em 
conformidade com a PSR-12 (substituta da PSR-2). Desse modo, 
nosso código fica mais organizado. 


O terceiro ponto a ser considerado é o tipo de retorno do método 
__invoke , que é especificado com : (dois pontos) após o parêntese 
de fechamento do método. O tipo de retorno definido nesse caso é 
EntityManager , que indica que o retorno deve ser obrigatoriamente 
desse tipo, ou seja, deve ser uma instância de EntityManager criada 
pelo Doctrine. 


Nosso próximo passo é registrar nossa Factory no arquivo de 
configuração config/dependencies.global.php . Abra esse arquivo e 
insira o trecho de código a seguir dentro da chave Factories do 
array: 


Doctrine\ORM\EntityManager::class => 
\App\Doctrine\Factory\DoctrineORMFactory::class 


Nesse momento, o seu arquivo config/dependencies.global. php deve 
estar parecido com o da imagem a seguir: 


EE, dependencies.global.php 


Poct rine\ORM\EntityManager: : => \App\Doctrine\Factory\DoctrineORMFactory: : 





Figura 7.3: Registrando a Factory DoctrineORMFactory 


Perceba que estamos informando que o nome da classe 
Doctrine\ORM\EntityManager::class referencia a nossa Factory 
App\Doctrine\Factory\DoctrineORMFactory::class , QUE retorna a instancia 
de EntityManager COM as configurações setadas do Doctrine. 


Nosso ultimo passo é verificarmos se a integração do Doctrine foi 
realizada com sucesso, o que pode ser feito testando a conexão. Se 
o Doctrine retornar o objeto Entitymanager com as informações da 
conexão com o banco de dados, então a integração do Doctrine foi 
bem-sucedida. Para testarmos, vamos criar uma nova classe de 
handler Chamado TestDoctrineConnectionHandler dentro do diretório 
src/App/src/Handler , conforme mostra a imagem a seguir: 


projeto-mezzio 


bin 
config 
data 


Doctrine 

Handler 

(4% HomePageHandler.php 

(4 HomePageHandlerFactory.php 
© PingHandler.php 





© TestDoctrineConnectionHandler.php 


Figura 7.4: Criando o handler TestDoctrineConnectionHandler 


Em seguida, abra o arquivo e coloque o conteúdo a seguir dentro 
dele: 


<?php 

declare(strict types=1); 
namespace App\Handler; 

use Doctrine\ORM\EntityManager; 
use Psr\Http\{ 


Message\ResponselInterface, 
Message\ServerRequestinterface, 


ServeriRequestHandlerInterface 
}; 


use Laminas\Diactoros\Response\J sonResponse; 


class TestDoctrineConnectionHandler implements RequestHandlerInterface 


{ 
per 
* @var EntityManager 
ie 


private EntityManager $em; 


public function _ construct(EntityManager $em) 


{ 


$this->em = $em; 


pe 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
E 
public function handle(ServerRequestInterface $request): 
ResponseInterface 


{ 


$isConnected = $this->em->getConnection()->connect(); 
return new JsonResponse(['doctrine_is_connected' => 
$isConnected]); 


} 
} 


A classe TestDoctrineConnectionHandler é COMO um controller da 
arquitetura MVC. Quando definirmos a rota para utilizar esse 
recurso, é para essa classe que vamos apontar a rota - veremos 
isso no próximo passo. Essa classe realiza a implementação da 
interface Psr\Http\Server\RequestHandlerInterface , QUE traz consigo O 
método handle com o parâmetro grequest do tipo 
Psr\Http\Message\ServerRequestInterface . Perceba também que O tipo 
de retorno esperado pelo método é o 
Psr\Http\Message\ResponseInterface , Obtido através da instância da 
classe Laminas\Diactoros\Response\J sonResponse . Essa classe vai 


retornar as informações que estão contidas no array em formato 
JSON. Não ficou claro? Quando executarmos o teste você 
entenderá melhor. 


Nossa classe TestDoctrineConnectionHandler possui um método 
construtor que é responsável por passar como dependência um 
objeto EntityManager e essa dependência será passada pela Factory 
que criaremos mais adiante para a nossa classe. 


É importante ressaltar que nossa classe 
TestDoctrineConnectionHandler possui dois pontos importantes. O 
primeiro ponto é a declaração use de forma agrupada no 
namespace Psr\Http . Como já vimos essa funcionalidade 
anteriormente, não será explicada detalhadamente novamente. 
Apenas saiba que você pode agrupar quaisquer namespaces que 
possuam mais de um subnamespace. 


O segundo ponto é a utilização da tipagem do atributo da classe. 
Perceba no atributo private EntityManager $em que estamos 
informando o tipo do atributo $em como sendo EntityManager . Esse é 
um recurso disponibilizado a partir do PHP 7.4. 


A classe TestDoctrineConnectionHandler deve ser parecida com a da 
imagem a seguir: 


© TestDoctrineConnectionHandler.php 





Figura 7.5: Conteudo da classe TestDoctrineConnectionHandler 


Seguindo em frente, crie um diretório chamado Factory dentro do 
diretório Handler , e dentro dele crie uma classe chamada 
TestDoctrineConnectionHandlerFactory , QUE será responsável por 
realizar a injeção de dependência para a nossa classe 


TestDoctrineConnectionHandler . Sua estrutura de diretórios deve ser 
parecida com a da imagem a seguir: 
projeto-mezzio 
la bin 
config 
data 


public 





Figura 7.6: Criando o diretório Factory e a classe TestDoctrineConnectionHandlerFactory 


Criamos o diretório Factory para deixar nossa estrutura e código 
mais organizados, assim separamos as Factories dos handlers. Em 
seguida, abra a nossa classe TestDoctrineConnectionHandlerFactory € 
coloque o seguinte código nela: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory; 


use App\Handler\TestDoctrineConnectionHandler ; 
use Psr\Container\ContainerInterface; 


class TestDoctrineConnectionHandlerFactory 


{ 


public function _ invoke(ContainerInterface $container): 
TestDoctrineConnectionHandler 


{ 
fem = $container->get('Doctrine\ORM\EntityManager' ) ; 
return new TestDoctrineConnectionHandler($em) ; 


} 


Ja foi dito anteriormente que todas as Factories que criarmos 
deverão ter obrigatoriamente o método _ invoke , até ai nenhuma 
surpresa. Agora perceba que, nesta classe, estamos utilizando o 
método get do objeto containerInterface . Esse método é o 
responsável por recuperar a nossa configuração registrada no 
arquivo de configuração config/dependencies.global.php . 


Você lembra que informamos lá no arquivo de configuração que a 
chave Doctrine\ORM\EntityManager referencia a Factory que criamos 
para o Doctrine? Pois bem, nosso handler atual possui como 
dependência um objeto do tipo EntityManager e é exatamente isso 
que estamos fazendo, ou seja, estamos recuperando o objeto 
EntityManager através do NOSSO ServiceManager e estamos passando 
esse objeto para O NOSSO handler TestDoctrineConnectionHandler . 


Note mais uma vez, que estamos usando o modo estrito do PHP 7 e 
também estamos informando ao método que o tipo de retorno 
esperado é um objeto do tipo TestDoctrineconnectionHandler . Nesse 
momento, sua classe TestDoctrineConnectionHandlerFactory deve ser 
parecida com a da imagem a seguir: 





Figura 7.7: Factory TestDoctrineConnectionHandlerFactory 


Nosso próximo passo é criar a rota que vamos utilizar para 
testarmos a conexão com o Doctrine. Para isso, abra o arquivo 
config/routes.php e coloque o seguinte código dentro da Closure 
(função anônima) embaixo da última rota criada: 


$app->get('/api/test-doctrine-connection', 
App\Handler\TestDoctrineConnectionHandler::class, 'api.test-doctrine- 
connection'); 


Nesse momento, seu código deve ser parecido com o demonstrado 
a seguir: 


<?php 
declare(strict_types=1) ; 


use Mezzio\Application; 
use Mezzio\MiddlewareFactory; 
use PsriContaineriContainerInterface; 


return function (Application $app, MiddlewareFactory $factory, 
ContainerInterface $container) : void { 
$app->get('/', App\Handler\HomePageHandler::class, ‘home'); 
$app->get('/api/ping', App\Handler\PingHandler::class, 'api.ping'); 
$app->get('/api/test-doctrine-connection', 


App\Handler\TestDoctrineConnectionHandler::class, 'api.test-doctrine- 
connection' ); 


}; 


Perceba que é um arquivo bastante simples, e o único ponto a ser 
observado é que todas as rotas criadas devem estar dentro da 
função anônima e observe ainda que o tipo de retorno dessa função 
é void, OU Seja, a função não retorna valores. Para criarmos uma 
rota, ela deve ter obrigatoriamente o tipo e o middleware, que no 
caso é o nosso handler App\Handler\TestDoctrineConnectionHandler . O 
terceiro parámetro do método get é opcional e nele especificamos o 
nome para uma determinada rota, que no nosso caso chamamos de 


api.test-doctrine-connection . 


Nosso último passo é registrar o nosso handler e a Factory do nosso 
handler na classe src/App/src/ConfigProvider.php para que possamos 
realizar uma chamada para a rota que acabamos de criar. Abra o 
arquivo src/App/src/ConfigProvider.php e coloque o código a seguir no 
método getDependencies dentro da chave Factories do array 
retornado pelo método: 


Handler\TestDoctrineConnectionHandler::class => 
Handler\Factory\TestDoctrineConnectionHandlerFactory::class 


O seu método getDependencies deve ser parecido com o código 
demonstrado a seguir: 


<?php 
per 
* Returns the container dependencies 
*/ 
public function getDependencies() : array 
{ 
return [ 


'invokables' => [ 
Handler\PingHandler::class => Handler\PingHandler::class, 
], 
"factories' => [ 
Handler\HomePageHandler::class => 
Handler\HomePageHandlerFactory::class, 


Handler\TestDoctrineConnectionHandler::class => 
Handler\Factory\TestDoctrineConnectionHandlerFactory::class, 


] 
1; 
} 


Perceba que registramos tanto O TestDoctrineConnectionHandler 
quanto a sua Factory TestDoctrineConnectionHandlerFactory , QUE realiza 
a injeção de dependência do objeto EntityManager do Doctrine. 


Finalmente, finalizamos a parte da criação. Pode parecer 
complicado à primeira vista, mas na verdade é apenas trabalhoso, 
pois tudo o que fizermos no Mezzio tem que ser especificado e 
registrado. Não se preocupe porque logo mais você estará 
acostumado com esse trabalho e conseguirá fazer seus códigos 
sem dificuldades. 


Agora que finalizamos, devemos testar nossa rota para termos a 
certeza de que o Doctrine está configurado corretamente. Para 
realizar esse teste, você pode utilizar um cliente que efetua 
requisições como o Postman, SOAP Ui etc. Você pode utilizar até 
mesmo o navegador, já que a rota é do tipo cet . Isso funcionará 
sem nenhum problema, ok? Em meu caso, estou utilizando o 
Postman para realizar os testes. Para testar, abra o cliente que você 
utilizará e digite http://projeto-mezzio.local/api/test-doctrine- 
connection €, em seguida, tecle enter, O resultado deve ser 
semelhante ao mostrado na imagem a seguir: 


COMO UTILIZAR O POSTMAN 


Para utilizar o Postman, basta você fazer o download do App no 
link https://www.getpostman.com/apps/ de acordo com a sua 


plataforma, instalar ou descompactar. Após a instalação ou 
descompactação, basta abrir o Postman e colocar a URL 
desejada, selecionar o tipo de requisição desejada GET, POST, 
PUT, PATCH, DELETE etc. e clicar em send. 





GET vy  http://projeto-mezzio.local/api/test-doctrine-connection 


KEY VALUE 


Body (6) 


Pretty BETA — 


yl 


1 
2 "doctrine is connected": true 
23 


Figura 7.8: Resultado do teste de conexáo do Doctrine 


Se o resultado obtido for semelhante ao da imagem anterior, entáo 
parabéns! Isso significa que vocé configurou e integrou 
corretamente o Doctrine ao seu projeto. Perceba que a chave 
doctrine_is_connected é igual a true, indicando que a conexão do 
Doctrine com o banco de dados foi bem-sucedida. Se a sua 
resposta tiver sido diferente de true então revise os passos até aqui 
com calma e atenção e tente novamente, que tudo dará certo :). 


7.2 Gerando entidades automaticamente 


Com o nosso banco de dados devidamente criado e importado, e 
com o Doctrine devidamente integrado ao Mezzio, chegou a hora de 
gerarmos as entidades com base em nossas tabelas do banco de 
dados. 


O Doctrine nos permite gerar as entidades de forma rápida e é isso 
que faremos. Se você ainda está um pouco confuso sobre o que 


significa uma "entidade" ou entity , imagine que é transformar as 
tabelas do nosso banco de dados em classes PHP. E muito 
semelhante a uma model da arquitetura MVC. 


Para gerarmos as entidades, entre na raiz do nosso projeto e 
execute o comando a seguir: 


php vendor/bin/doctrine orm:convert-mapping --from-database annotation 
src/App/src/Entity/ 


O comando anterior informa ao Doctrine para gerar as entidades por 
meio do banco de dados e salvá-las no diretório src/App/src/Entity . 
Caso o diretório ainda não exista, então crie-o e execute o comando 
novamente. Após a execução do comando, você deverá visualizar 
uma saída semelhante à mostrada na imagem a seguir: 

Processing entity " 


Processing entity " 
Processing entity " 





Exporting " " mapping information to " 


Figura 7.9: Gerando Entidades com o Doctrine 


A imagem mostra que as entidades foram geradas com sucesso, e 
se abrirmos o diretorio Entity poderemos ver as entidades que 
foram geradas, conforme mostra a imagem a seguir: 


projeto-mezzio 


| bin 
E confio 
| data 
public 





| Doctrine 


Ej Mensagens.php 
a TiposUsuario.php 






Es Usuarios.php 


Figura 7.10: Entidades geradas dentro do diretório Entity 
Conclusáo 


Chegamos ao final de mais um capítulo, em que foi demonstrado 
como integrar e configurar o Doctrine ORM no Mezzio e se vocé já 
realizou a integracáo anteriormente com o extinto Zend Expressive, 
verá que é exatamente a mesma coisa. Também vimos como criar e 
registrar um novo handler e definimos uma nova rota para que 
pudéssemos testar se a conexáo do Doctrine com o banco de dados 
foi efetuada com sucesso. 


A partir do proximo capitulo, vamos iniciar uma série de trés 
capitulos nos quais vamos melhorar as entidades que foram 
geradas pelo Doctrine. Vamos criar os métodos getters € setters , 
utilizar um componente do Laminas chamado Laminas Hydrator, 
que fara com que as nossas entidades possam ter o conteudo 
setado de forma mais rapida e eficaz, e também vamos utilizar 
alguns componentes para criação de senha, tornando-a mais 
segura. Entao, siga em frente e vamos nessa! 


CAPITULO 8 
Melhorando a entidade TiposUsuario 


No capítulo anterior geramos as entidades utilizando o Doctrine, 
porém precisamos melhorá-las, criando os métodos básicos de uma 
entidade, definindo o repositório de cada uma etc. Antes de 
iniciarmos as modificações em nossas entidades, nós vamos 
conhecer e integrar o componente Laminas Hydrator em nossa 
aplicação. 


O QUE É O LAMINAS HYDRATOR? 


É um componente do Laminas responsável por realizar a 
hidratação de dados, o que chamamos de popular um objeto 


com determinados dados. O Laminas Hydrator é simples e 
fornece métodos para hidratar/popular o objeto e também 
fornece para extrair seus dados. 





Vale ressaltar que vamos utilizar o Laminas Hydrator em nosso 
projeto porque ele facilitará nossa vida tanto para popular os objetos 
quanto para extrair os dados do objeto. 


Então vamos instalar o componente. Para isso, abra o seu terminal, 
vá até a raiz do projeto e execute o seguinte comando para realizar 
a instalação: 


composer require laminas/laminas-hydrator 


Após executar o comando anterior, aparecerá uma mensagem para 
que você selecione se deseja injetar o Laminas Hydrator no arquivo 
de configuração ou não. Selecione a opção 1 para injetar o 
Laminas Hydrator no arquivo de configuração e, em seguida, tecle 
ENTER para prosseguir com a instalação. 


Em seguida, sera exibida uma pergunta informando se vocé deseja 
relembrar a opção de injetar o componente no arquivo de 
configuração para as próximas instalações de componentes, informe 
y (sim) e tecle ENTER para prosseguir com a instalação. Após a 
execução desses passos, você deverá visualizar uma saída 
semelhante à exibida na imagem a seguir: 


Do not run Composer as root/super user! See https://getcomposer.orc 
Using version 


- Installing (3.0.2): Downloading (100% 


[9] Do not inject 
[1] config/config.php 
Make your selection (default is 1):1 


y 


laminas/laminas-hydrator suggests installing laminas/laminas-seria 
Package container-interop/container-interop is abandoned, you shoul 


Generating version class... 
...done generating version class 





Figura 8.1: Clonando e registrando o componente Laminas Hydrator 


Excelente, o Laminas Hydrator está integrado ao Mezzio e podemos 
seguir em frente. Uma dependência atual do Laminas Hydrator é o 
Laminas Filter, então devemos instalá-lo também. Internamente, o 
Laminas Hydrator utiliza o componente Laminas Filter para realizar 
a filtragem dos dados enviados para serem hidratados. 


O QUE É O LAMINAS FILTER? 


É um componente do Laminas responsável por realizar a 


filtragem de dados, como transformar uma string em letras 
maiúsculas ou minúsculas. O Laminas Filter é simples e fornece 
métodos para realizar o tratamento adequado. 





Para instalar o componente Laminas Filter, execute o comando a 
seguir: 


composer require laminas/laminas-filter 


Novamente, após executar o comando anterior, aparecerá uma 
mensagem para que você selecione se deseja injetar o Laminas 
Filter no arquivo de configuração ou não. Selecione a opção 1 para 
injetar o Laminas Filter no arquivo de configuração e, em seguida, 
tecle ENTER para prosseguir com a instalação. 


Após a instalação bem-sucedida do componente Laminas Filter 
você deverá ver uma saída semelhante à mostrada na imagem a 
seguir: 


Do not run Composer as root/super user! See https://getcomposer.org/root for det 


Using version 


- Installing (2.9.3): Downloading (100%) 


[9] Do not inject 
[1] config/config.php 


Make your selection (default is 1):1 


y 


laminas/laminas-filter suggests installing laminas/laminas-crypt (Laminas\Crypt 

laminas/laminas-filter suggests installing laminas/laminas-il8n (Laminas\I18n co 
laminas/laminas-filter suggests installing laminas/laminas-uri (Laminas\Uri comp 
Package container-interop/container-interop is abandoned, you should avoid using 


Generating version class... 
...done generating version class 





Figura 8.2: Clonando e registrando o componente Laminas Filter 


Agora que temos a dependência do Laminas Hydrator instalada em 
nossa aplicação, podemos seguir em frente na melhoria de nossas 
entidades. 


A primeira entidade em que vamos fazer nossas alterações será a 
TiposUsuario , que é responsável pelos tipos de usuários da 
aplicação. Abra essa entidade em sua IDE. Perceba que ela não 
possui namespace e nenhum método criado. Perceba que o nome da 
entidade é exatamente o mesmo nome da tabela que foi criada no 
banco de dados, e as propriedades da entidade são exatamente os 
campos da tabela no MySQL. O que faremos para todas as 
entidades será: 


e Definir modo estrito do PHP 7; 

e Definir namespace; 

e Ajustar os atributos e definir seus tipos 
Definir repositório; 

e Definir métodos. 


Então, seguindo essa linha de raciocínio, vamos para o primeiro 
item da lista. 


Definindo o Modo Estrito do PHP 7 


Antes de seguirmos, vamos habilitar o modo estrito do PHP 7 
inserindo o código a seguir logo após a tag de abertura do PHP: 


declare(strict types=1); 


Após habilitar o modo estrito da sua entidade, ela deve estar 
parecida com a da imagem a seguir: 


a Ti pos Usuario. p h p 


TiposUsuario 





Figura 8.3: Habilitando o modo estrito do PHP 7 na entidade TipoUsuario 
Definindo o namespace 


Nosso próximo passo é definir o namespace da entidade. Como 
você pôde perceber, as entidades não possuem um namespace 
após sua geração pelo Doctrine. Então, vamos defini-lo. Coloque o 
código a seguir no começo da sua entidade, antes do nome da 
classe e até mesmo antes da declaração use : 


namespace App\Entity; 


Após essa alteração, sua entidade deve ter uma definição de 
namespace semelhante à da imagem a seguir: 


(5 TiposUsuario.php 


(strict_typ 


App\Entity 





Figura 8.4: Definindo namespace para a entidade TipoUsuario 
Ajustando os atributos e definindo seus tipos 


Agora temos que alterar o nome das propriedades da entidade para 
torná-las mais legíveis e de mais fácil compreensão. Para isso, 
faremos conforme o código a seguir: 


¡Ex 


* @var int 


* @ORM\Column(name="id", type=" integer", nullable=false) 
* @ORM\Id 
* @ORM\GeneratedValue(strategy=" IDENTITY" ) 
e 
private Pint $id; 


per 
* @var string 
* 


* @ORM\Column(name="tipo", type=" string", length=45, nullable=false, 
options={" comment" =" Tipo" y) 

a 
private string $tipo; 


/** 

* @var bool 

* 

* @ORM\Column(name="ativo", type="boolean", nullable=false, options= 
{" default" =" 1" ," comment" =" Está ativo? 


© - Nao 
1 - Sim')) 
a A 


private bool fativo = true; 


pex 

* @var \DateTime 

* 

* @ORM\Column(name="criado_em", type="datetime", nullable=false, options= 
{" default" ="CURRENT_TIMESTAMP" ," comment" ="Data de criação" }) 

*/ 

private \DateTime $criadoEm; 


per 

* @var \DateTime| null 

* 

* @ORM\Column(name="alterado_em", type=" datetime", nullable=true, 
options={" comment" ="Data de alteração" y) 


E é 


private ?\DateTime $alteradoEm = null; 


per 
* @var \DateTime| null 
* 


* @ORM\Column(name="deletado_em", type=" datetime", nullable=true, 
options={" comment" ="Data de exclusão" }) 

*/ 

private ?\DateTime $deletadoEm = null; 


Há dois pontos importantes a serem explicados referentes ao código 
dos atributos. Primeiramente, observe que após a declaração de 
visibilidade private dos atributos estamos definindo o tipo para cada 
um deles - funcionalidade disponibilizada no PHP 7.4, conforme 
vimos no capítulo anterior. O segundo ponto a ser notado é a 
utilização do sinal de interrogação > na tipagem dos atributos $id, 
$alteradoEm @ $deletadoEm . Isso indica que o atributo é opcional e, 
caso o atributo não possua o valor do tipo DateTime informado, será 
definido o valor nu11 . Um ponto importante a ser considerado é que 
o atributo $ia não terá valor definido, ou seja, não definiremos um 
valor para ele porque isso será feito automaticamente pelo Doctrine 
com a utilização do autoincremento do MySQL. 


Nosso próximo passo é definir o repositório para a nossa entidade. 
Definindo o repositório na entidade 


Um repositório é uma classe responsável por conter métodos que se 
comunicam de forma mais direta com o banco de dados. Como 
estamos utilizando o Doctrine, essa comunicação é realizada 
através da linguagem DQL (Doctrine Query Language), que nada 
mais é que o SQL, mas adaptado com algumas características do 
Doctrine. 


Definir um repositório para a nossa entidade é bem simples e se dá 
por meio de annotation (anotação). Coloque o código a seguir em 
sua entidade, substituindo a annotation @orm\Entity , que está 
localizada acima do nome da classe: 


@ORM\Entity(repositoryClass= ) 


Após a definição do repositório TiposusuarioRepository sua entidade 
deve ser semelhante à mostrada na imagem a seguir: 


© TiposUsuario.php 





Figura 8.5: Definindo repositório na entidade TiposUsuario 


Perceba que definimos o repositório com o namespace 
App\Repository\TiposUsuarioRepository , mas o diretório e a classe no 
momento não existem ainda. Faremos isso em nosso próximo 
capítulo, em que focaremos na criação dos repositórios das 
entidades, então não se preocupe. 


Definindo os métodos da entidade TiposUsuario 


Como foi dito anteriormente, as entidades que geramos pelo 
Doctrine não possuem métodos e é exatamente isso que faremos 
agora. O primeiro que faremos é o método construtor _ construct , 
no qual já aplicaremos o componente Laminas Hydrator , responsável 
por setar os dados de forma automática quando a entidade for 
chamada. Coloque o código a seguir em sua entidade: 


use Laminas\Hydrator\ClassMethodsHydrator; 


Primeiramente, importe a classe classMethodsHydrator do 
componente Laminas Hydrator em sua entidade. Lembre-se de que a 
declaração use deve ficar abaixo do namespace da classe, junto 
com as outras declarações use , conforme mostra a imagem a 
seguir: 


© TiposUsuario.php 





Figura 8.6: Importando o Componente Zend Hydrator ClassMethods na Entidade 
TiposUsuario 


Após a importação da classe classMethodsHydrator , defina o 
construtor da entidade como no código a seguir: 


public function _ construct(array $data = []) 


{ 


$this->criadoEm = new \DateTime( ); 
(new ClassMethods())->hydrate($data, $this); 
} 


Observe que ele possui como parâmetro um array de dados que, 
se não for passado, automaticamente assumirá um array vazio. 
Estamos instanciando a classe classmethodsHydrator €, em seguida, 
já estamos chamando o método hydrate passando como 
parâmetros a variável $data e o objeto $this , que referencia a 


própria entidade. O hydrate vai comparar os métodos setters da 
nossa entidade com o nome das chaves enviadas no array de 
dados. A cada checagem bem-sucedida, O hydrate setará o valor 
contido na chave chamando automaticamente o método 
correspondente. Dessa forma, ao utilizarmos a entidade para setar 
valores, não precisaremos fazer: 


$tipoUsuario = new TiposUsuario(); 
$tipoUsuario->setTipo('Teste'); 
$tipoUsuario->setAtivo(true); 


[FEL **/ 


Outro ponto, se você perceber, é que estamos definindo que o 
atributo $this->criadoEm já possuirá o objeto \DateTime do PHP 
setado com a data e hora atual em que a entidade for executada. 


Agora que definimos o método construtor, vamos definir os métodos 
getters @ setters da nossa entidade. Observe atentamente o 
código a seguir, no qual estamos definindo os métodos juntamente 
com o tipo de retorno esperado: 


per 

* (return int 

E 

public function getId(): int 
{ 


return $this->id; 


pe 

* (return string 

#7 

public function getTipo(): string 
{ 


return $this->tipo; 


JET 
* @param string $tipo 
* @return TiposUsuario 


af 


public function setTipo(string $tipo): 


{ 
$this->tipo = $tipo; 
return $this; 


per 
* (return bool 
ef 
public function isAtivo(): bool 


1 


return $this->ativo; 


¡Er 
* @param bool fativo 
* (return TiposUsuario 


e 


public function setAtivo(bool $ativo): 


{ 
$this->ativo = fativo; 
return $this; 


¡Er 
* (return \DateTime 


e 


TiposUsuario 


TiposUsuario 


public function getCriadoEm(): \DateTime 


{ 


return $this->criadoEm; 


JFF 
* @return TiposUsuario 


e 


public function setCriadoEm(): TiposUsuario 


{ 


$this->criadoEm = new \DateTime('now'); 


return $this; 


per 

* (return DateTime) null 

*/ 

public function getAlteradoEm(): ?\DateTime 
{ 


return $this->alteradoEm; 


pr 
* @return TiposUsuario 
ed 
public function setAlteradoEm(): TiposUsuario 


{ 


$this->alteradoEm = new \DateTime('now'); 
return $this; 


per 

* @return \DateTime] null 

a 

public function getDeletadoEm(): ?\DateTime 
{ 


return $this->deletadoEm; 


JER 

* @return TiposUsuario 

ef 

public function setDeletadoEm(): TiposUsuario 


{ 
$this->deletadoEm = new ADateTime('now'); 
return $this; 


} 


Perceba que os métodos setters possuem o retorno do tipo 
TiposUsuario esperado. Isso significa que estamos trabalhando com 
interface fluente, ou seja, podemos chamar vários métodos setters 
sem a necessidade de chamar a variável do objeto como fizemos 
anteriormente: 


$tipoUsuario = new TipoUsuario(); 
$tipoUsuario->setTipo('Teste'); 
$tipoUsuario->setAtivo(true) ; 


[Ek **/ 


Através da interface fluente, podemos chamar os métodos da 
seguinte maneira: 


$tipoUsuario = new TipoUsuario(); 
$tipoUsuario->setTipo('Teste' ) 


->setAtivo(true) ; 
[** 2. **/ 


Simples, não é mesmo? Perceba que os métodos getalteradoEm € 
getDeletadoEm possuem o tipo de retorno ?\DateTime.O ? no retorno 
indica que o retorno pode ser do tipo \DateTime OU null é a mesma 
coisa que fizemos com os atributos, isso porque em nosso banco de 
dados as colunas alterado em @ deletado em Não possuem 
preenchimento obrigatório. 


Se você observou atentamente os métodos criados, deve ter 
percebido que não possuímos o método setid . O motivo é que o 
campo id no banco de dados é autoincremento, ou seja, o valor 
será incrementado automaticamente. Por esse motivo, não criamos 
o método setid. 


Para finalizarmos, falta criarmos o método toarray que será 
responsável por pegar todos os dados da entidade e retorná-los em 
forma de array. Observe o código a seguir: 


per 
* (return array 
“7 
public function toArray(): array 


{ 
return (new ClassMethodsHydrator())->extract($this); 


} 


Perceba que estamos utilizando novamente a classe 
ClassMethodsHydrator , mas dessa vez para retornar todos os dados do 


objeto em forma de array. O método extract da classe 
ClassMethodsHydrator recebe como parâmetro um objeto, que no 
nosso caso é a própria entidade representada pelo objeto $this. 


Com isso, finalizamos as alterações em nossa entidade 
TiposUsuario , Você pode ver o código completo dela a seguir: 


<?php 
declare(strict types=1); 
namespace App\Entity; 


use Doctrine\ORM\Mapping as ORM; 
use Laminas\Hydrator\ClassMethodsHydrator; 


per 
* TiposUsuario 
* 
* @ORM\Table(name="tipos usuario") 
* @ORM\Entity(repositoryClass="App\Repository\TiposUsuarioRepository” ) 
a É 
class TiposUsuario 
{ 
JEF 
* @var int 
* 
* @ORM\Column(name=" id", type=" integer", nullable=false) 
* @ORM\Id 
* @ORM\GeneratedValue(strategy=" IDENTITY" ) 
+ 
private Pint $id; 


prt 
* @var string 
* 
* @ORM\Column(name="tipo", type=" string", length=45, nullable=false, 
options={" comment" =" Tipo" y) 
27 
private string $tipo; 


¡Er 
* @var bool 
* 
* @ORM\Column(name="ativo", type="boolean", nullable=false, options= 
{" default" =" 1" ," comment" =" Está ativo? 


© - Nao 
1 - Sim"}) 
*/ 


private bool $ativo = true; 


per 
* @var \DateTime 
* 
* @ORM\Column(name="criado_em", type="datetime", nullable=false, 
options={" default" ="CURRENT_TIMESTAMP" ," comment" =" Data de criação" }) 
+f 
private \DateTime $criadoEm; 


per 
* @var \DateTime| null 
* 
* @ORM\Column(name="alterado_em", type=" datetime", nullable=true, 
options={" comment" ="Data de alteração" 3) 
irá 
private ?\DateTime $alteradoEm = null; 


pes 
* @var \DateTime| null 
* 


* @ORM\Column(name="deletado_em", type=" datetime", nullable=true, 
options={" comment" ="Data de exclusão" }) 
*/ 
private ?\DateTime $deletadoEm = null; 


per 
* TiposUsuario constructor. 
* @param array $data 
rd 
public function __construct(array $data = []) 


{ 


$this->criadoEm = new \DateTime('now'); 
(new ClassMethodsHydrator())->hydrate($data, $this); 


per 

* return int 

i 

public function getId(): int 
{ 


return $this->id; 


pr 


* return string 


ay 
public function getTipo(): string 
{ 
return $this->tipo; 
} 
JFF 


* @param string $tipo 
* @return TiposUsuario 
À 
public function setTipo(string $tipo): TiposUsuario 
{ 
$this->tipo = $tipo; 
return $this; 


per 
* @return bool 
uy 
public function isAtivo(): bool 


{ 


return $this->ativo; 


per 
* @param bool fativo 
* @return TiposUsuario 


*/ 
public function setAtivo(bool $ativo): TiposUsuario 


{ 
$this->ativo = $ativo; 
return $this; 


/** 

* @return \DateTime 

ae 

public function getCriadoEm(): \DateTime 
{ 


return $this->criadoEm; 


ptt 
* @return TiposUsuario 
ay 
public function setCriadoEm(): TiposUsuario 


{ 
$this->criadoEm = new \DateTime('now'); 
return $this; 


JEF 

* @return \DateTime| null 

*7 

public function getAlteradoEm(): ?\DateTime 
{ 


return $this->alteradoEm; 


per 
* @return TiposUsuario 
*] 
public function setAlteradoEm(): TiposUsuario 


{ 


$this->alteradoEm = new \DateTime('now'); 
return $this; 


per 


* @return ADateTime null 


*/ 
public function getDeletadoEm(): ?\DateTime 
{ 
return $this->deletadoEm; 
} 
Y Adi 
* @return TiposUsuario 
ay 
public function setDeletadoEm(): TiposUsuario 
{ 
$this->deletadoEm = new \DateTime('now'); 
return $this; 
} 
per 
* (return array 
EA 
public function toArray(): array 
{ 
return (new ClassMethodsHydrator())->extract($this) ; 
} 
} 
Conclusão 


Chegamos ao final do capítulo, vimos aqui como melhorar nossa 
entidade TiposUsuario que foi gerada pelo Doctrine, ajustando os 
atributos e definindo o tipo de cada um deles, definindo namespace, 
criando métodos, ativando o modo estrito do PHP 7 e definindo o 
repositório dela. Conhecemos também o componente Laminas 
Hydrator que agiliza nosso desenvolvimento atribuindo os valores 
para os atributos da classe de forma automática, através de seus 
métodos setters . Conseguimos também obter o conjunto de valores 
dos atributos da classe em forma de array. 


No proximo capitulo vamos melhorar a entidade usuarios igual 
fizemos com a nossa entidade Tiposusuario . Então, siga em frente e 
vamos nessa! 


CAPITULO 9 
Melhorando a entidade Usuarios 


Assim como fizemos com a entidade TiposUsuario , também faremos 
com a entidade usuarios , porém, como as alterações sao do mesmo 
tipo, nao sera detalhado tao na integra como fizemos na anterior. No 
fim desta seção você poderá ver o código completo da entidade. 


Definindo o modo estrito do PHP 7 


Agora vamos habilitar o modo estrito do PHP 7 inserindo o código a 
seguir logo após a tag de abertura do PHP: 


declare(strict types=1); 
Definindo o namespace 


Nosso próximo passo é definir o namespace da entidade. Como dito 
anteriormente, as entidades não possuem um namespace definido 
após sua geração pelo Doctrine. Coloque o código a seguir no 
começo da sua entidade, antes do nome da classe e até mesmo 
antes da declaração use : 


namespace App\Entity; 
Ajustando os atributos e definindo seus tipos 


Assim como fizemos com a nossa entidade TiposUsuario , também 
temos que ajustar alguns atributos da entidade e definir o tipo de 
cada um. Confira o código a seguir e faça o mesmo com a sua 
entidade usuarios : 


per 
* @var int 
* 
* @ORM\Column(name="id" , type=" integer", nullable=false) 
* @ORM\Id 


* @ORM\GeneratedValue(strategy=" IDENTITY" ) 
uy 
private Pint $id; 


pre 


* @var TiposUsuario 


* @ORM\ManyToOne(targetEntity=" TiposUsuario” ) 
* @ORM\J oinColumns({ 
* — @ORM\J oinColumn(name="tipo_usuario_id", referencedColumnName=" id") 
* 3) 
i 
private $tipoUsuario; 


per 
* @var string 
* 


* @ORM\Column(name="nome_completo", type=" string", length=150, 
nullable=false, options={" comment" ="Nome completo do usuario" y) 
ae 
private string $nomeCompleto ; 


per 

* @var string 

* 

* @ORM\Column(name="cpf", type=" string", length=11, nullable=false, 
options={" comment" =" CPF" )) 

*/ 
private string $cpf; 


pes 
* @var \DateTime 
* 


* @ORM\Column(name="data_nascimento", type="date", nullable=false, 
options={" comment" ="Data de nascimento" }) 

*/ 
private \DateTime $dataNascimento; 


¡Ex 
* @var string 
* 


* @ORM\Column(name="email", type="string", length=100, nullable=false) 
e 
private string femail; 


per 

* @var string 

* 

* @ORM\Column(name="senha", type=" string", length=255, nullable=false, 
options={" comment" =" Senha" )) 

“sp 
private string $senha; 


per 

* @var bool 

* 

* @ORM\Column(name="ativo", type="boolean", nullable=false, options= 
{" default" =" 1" ," comment" =" Está ativo? 


© - Nao 
1 - Sim')) 
*/ 


private bool fativo = true; 


per 
* @var \DateTime 
* 
* @ORM\Column(name="criado_em", type="datetime", nullable=false, options= 
{" default" ="CURRENT_TIMESTAMP" ," comment" =" Data de criação do registro" }) 
*7 
private \DateTime $criadoEm; 


JEF 

* @var \DateTime| null 

* 

* @ORM\Column(name="alterado_em", type=" datetime", nullable=true, 
options={" comment" ="Data de alteração do registro" }) 

*/ 
private ?\DateTime $alteradoEm = null; 


¡Ex 
* @var \DateTime| null 
* 


* @ORM\Column(name="deletado_em", type=" datetime" , nullable=true, 
options={" comment" ="Data de exclusão do registro" }) 

Ef 

private ?\DateTime $deletadoEm = null; 


Um ponto a ser considerado é o atributo $tipoUsuario , que possui 
relacionamento com a entidade TiposUsuario . 


Definindo o repositório na entidade 


Escreva o código a seguir em sua entidade, substituindo a 
annotation (anotação) @orm\Entity que está localizada acima do 
nome da classe: 


@ORM\Entity(repositoryClass="App\Repository\UsuariosRepository" ) 
Definindo os métodos da entidade usuarios 


Nosso último passo para a nossa entidade é definirmos os métodos. 
Mas antes de escrevermos os métodos, precisamos importar a 
classe classMethodsHydrator para dentro da nossa entidade. Para 
isso, coloque o código a seguir, após o namespace de sua entidade: 


use Laminas\Hydrator\ClassMethodsHydrator ; 


Após a importação do classMethodsHydrator , podemos escrever os 
nossos métodos. Escreva o código a seguir em sua entidade: 


per 
* Usuarios constructor. 
* @param array $data 
ad 
public function _ construct(array $data = []) 
{ 
$this->criadoEm = new \DateTime('now'); 
(new ClassMethodsHydrator())->hydrate($data, $this); 


JEF 


* @return int 


a 
public function getId(): int 
{ 


return $this->id; 


per 
* (return TiposUsuario 
+ 
public function getTipoUsuario(): TiposUsuario 


{ 


return $this->tipoUsuario; 


/** 
* @param TiposUsuario $tipoUsuario 
* @return Usuarios 


37 
public function setTipoUsuario(?TiposUsuario $tipoUsuario): 
{ 
$this->tipoUsuario = $tipoUsuario; 
return $this; 
} 
[er 
* @return string 
nd 
public function getNomeCompleto(): string 
{ 
return $this->nomeCompleto; 
} 
per 


* @param string $nomeCompleto 
* @return Usuarios 


e 


Usuarios 


public function setNomeCompleto(string $nomeCompleto): Usuarios 


{ 
$this->nomeCompleto = $nomeCompleto; 
return $this; 


¡Ex 


* (return string 


2y 
public function getCpf(): string 
{ 
return $this->cpf; 
} 
| 


* @param string $cpf 
* @return Usuarios 
*/ 
public function setCpf(string $cpf): Usuarios 
{ 
$this->cpf = $cpf; 
return $this; 


} 
[te 

* @return \DateTime 

4 

public function getDataNascimento(): DateTime 
{ 

return $this->dataNascimento; 

} 
per 


* @param \DateTime $dataNascimento 
* (return Usuarios 
e é 
public function setDataNascimento (DateTime $dataNascimento): Usuarios 
{ 
$this->dataNascimento = $dataNascimento; 
return $this; 


¡Ex 
* @return string 
ar 
public function getEmail(): string 


return $this->email; 


JEF 
* @param string $email 
* @return Usuarios 
*/ 
public function setEmail(string $email): Usuarios 
{ 
$this->email = $email; 
return $this; 


JEF 

* @return string 

a 

public function getSenha(): string 
{ 


return $this->senha; 


per 
* @param string $senha 
* @return Usuarios 
Er 
public function setSenha(string $senha): Usuarios 
{ 
$this->senha = $this->encriptarSenha($senha) ; 
return $this; 


} 
per 

* @return bool 

7 
public function isAtivo(): bool 
{ 

return $this->ativo; 

} 


JEF 


* @param bool $ativo 
* @return Usuarios 
*/ 
public function setAtivo(bool $ativo): Usuarios 
{ 
$this->ativo = $ativo; 
return $this; 


[rr 

* @return \DateTime 

a 

public function getCriadoEm(): \DateTime 
{ 


return $this->criadoEm; 


per 
* @return Usuarios 
sd 
public function setCriadoEm(): Usuarios 
{ 
$this->criadoEm = new \DateTime('now'); 
return $this; 


per 

* @return \DateTime| null 

“7 

public function getAlteradoEm(): ?\DateTime 
{ 


return $this->alteradoEm; 


per 
* (return Usuarios 
ep 
public function setAlteradoEm(): Usuarios 
{ 
$this->alteradoEm = new ADateTime('now'); 
return $this; 


per 

* @return \DateTime] null 

eE 

public function getDeletadoEm(): ?\DateTime 
{ 


return $this->deletadoEm; 


JET 
* @return Usuarios 
EA 
public function setDeletadoEm(): Usuarios 


{ 


$this->deletadoEm = new \DateTime('now'); 
return $this; 


per 
* @param string $senha 
* @return string 


*/ 


public function encriptarSenha(string $senha): 


{ 


return md5($senha); 


per 
* (return array 
uid 
public function toArray(): array 


{ 


string 


return (new ClassMethodsHydrator())->extract($this); 


} 


A novidade em nossa entidade é o método encriptarSenha que, 
como o próprio nome já diz, é responsável por realizar a encriptação 
da senha do usuario. Aqui vamos utilizar o mds do PHP porque é 
simples e atende bem o que deve ser mostrado, mas você pode 


tentar implementar outro algoritmo de encriptação, como O sha256 , 
por exemplo. 


Chegamos ao fim das alterações de mais uma entidade, e como o 
código completo dela é grande, você poderá conferi-lo no GitHub: 
https://github.com/jhones/projeto- 
mezzio/blob/master/src/App/src/Entity/Usuarios.php/. 


Conclusão 


Neste capítulo, vimos como melhorar nossa entidade usuarios, que 
foi gerada pelo Doctrine, ajustamos alguns atributos e definimos o 
tipo de cada atributo da entidade. Também definimos o namespace, 
criamos os métodos, ativamos o modo estrito do PHP 7 e definimos 
o repositório da nossa entidade. 


No próximo capítulo, vamos melhorar a entidade mensagens como 
fizemos com as entidades TiposUsuario € Usuarios . Então, siga em 
frente e vamos nessa! 


CAPITULO 10 
Melhorando a entidade Mensagens 


Por fim, vamos realizar as alterações em nossa última entidade. 
Vamos em frente! 


Definindo o modo estrito do PHP 7 


Vamos habilitar o modo estrito do PHP 7 inserindo o código a seguir 
logo após a tag de abertura do PHP: 


declare(strict types=1); 
Definindo o namespace 


Para definir o namespace, escreva o código a seguir no começo da 
sua entidade, antes do nome da classe e antes da declaração use: 


namespace App\Entity; 
Ajustando os atributos e definindo seus tipos 


Assim como fizemos com as outras entidades, também temos que 
ajustar alguns atributos e definir o tipo de cada um. Confira o código 
a seguir e faça o mesmo com a sua entidade mensagens : 


per 
* @var int 
* 
* @ORM\Column(name="id", type=" integer", nullable=false) 
* @ORM\Id 
* @ORM\GeneratedValue(strategy=" IDENTITY" ) 
“7 


private Pint $id; 


per 
* @var Usuarios 
* 


* @ORM\ManyToOne(targetEntity="Usuarios” ) 
* @ORM\J oinColumns (1 
* — @ORM\J oinColumn(name="usuario_id", referencedColumnName=" id") 
* }) 
sd 
private fusuario; 


¡Ex 
* @var string 
* 


* @ORM\Column(name="mensagem", type="text", length=65535, nullable=false, 
options={" comment" =" Descrição da mensagem" }) 
*7 


private string $mensagem; 


per 
* @var string| null 
* 
* @ORM\Column(name="resposta", type="text", length=65535, nullable=true) 
af 
private ?string $resposta = null; 


per 

* @var \DateTime 

* 

* @ORM\Column(name="data_mensagem", type=" datetime", nullable=false, 
options={" comment" ="Data da mensagem" }) 

*/ 
private \DateTime $dataMensagem; 


pes 

* @var bool 

* 

* @ORM\Column(name="ativo", type="boolean", nullable=false, options= 
{" default" =" 1" ," comment" =" Está ativo? 


© - Não 
1 - Sim"}) 
4 


private bool fativo = true; 


per 


* @var \DateTime 
* 


* @ORM\Column(name="criado_em", type="datetime", nullable=false, options= 
{" default" =" CURRENT_TIMESTAMP" 3) 
lt 


private \DateTime $criadoEm; 


per 
* @var \DateTime| null 
* 


* @ORM\Column(name="alterado_em", type=" datetime", nullable=true) 
ay 


private ?\DateTime $alteradoEm = null; 


per 
* @var \DateTime| null 
* 


* @ORM\Column(name="deletado_em", type=" datetime", nullable=true) 
*/ 
private ?\DateTime $deletadoEm = null; 


Perceba que nossa entidade mensagens também possui um 
relacionamento, que se dá pela propriedade $usuario , que se 
relaciona com a entidade Usuarios . 


Definindo o repositório na entidade 


Escreva o código a seguir em sua entidade, substituindo a 
annotation (anotação) @orMm\entity que está localizada acima do 
nome da classe: 


@ORM\Entity(repositoryClass=" App\Repository\MensagensRepository") 
Definindo os métodos da entidade mensagens 


Nosso último passo para a nossa entidade é definirmos os métodos. 
Mas antes de escrevermos os métodos, precisamos importar a 
classe ClassMethodsHydrator para dentro da nossa entidade. Para 
isso, coloque o código a seguir, após o namespace de sua entidade: 


use Laminas\Hydrator\ClassMethodsHydrator ; 


Após a importação do classMethodsHydrator , podemos escrever os 
nossos métodos. Escreva o código a seguir em sua entidade: 


per 
* Mensagens constructor. 
* @param array $data 
4 
public function _ construct(array $data = []) 
$this->criadoEm = new ADateTime('now'); 
(new ClassMethodsHydrator())->hydrate($data, $this); 


} 
per 
* @return int 
*/ 
public function getId(): int 
{ 
return $this->id; 
} 
JFF 
* @return string 
t 
public function getMensagem(): string 
{ 
return $this->mensagem; 
} 
per 


* @param string $mensagem 

* @return Mensagens 

*/ 
public function setMensagem(string $mensagem): Mensagens 
1 

$this->mensagem = $mensagem; 

return $this; 


per 
* return null| string 
*/ 
public function getResposta(): ?string 


{ 


return $this->resposta; 


JEF 
* @param null| string $resposta 
* @return Mensagens 


a 
public function setResposta(?string fresposta): 
{ 
$this->resposta = $resposta; 
return $this; 
} 
¡Ex 


* @return \DateTime 

A 
public function getDataMensagem(): DateTime 
{ 


return $this->dataMensagem; 


per 
* @param \DateTime $dataMensagem 
* @return Mensagens 
A 
public function setDataMensagem(): Mensagens 


{ 


$this->dataMensagem = new \DateTime('now'); 


return $this; 


per 
* @return bool 
rá 
public function isAtivo(): bool 


{ 


Mensagens 


return $this->ativo; 


[te 

* @param bool $ativo 

* @return Mensagens 

+} 
public function setAtivo(bool $ativo): Mensagens 
{ 

$this->ativo = fativo; 

return $this; 


pes 

* (return \DateTime 

j 
public function getCriadoEm(): \DateTime 
{ 


return $this->criadoEm; 


[ft 
* @return Mensagens 
+ 
public function setCriadoEm(): Mensagens 


{ 
$this->criadoEm = new \DateTime('now'); 
return $this; 


fr 

* @return \DateTime| null 

*/ 
public function getAlteradoEm(): ?\DateTime 
{ 


return $this->alteradoEm; 


pex 
* (return Mensagens 


é À 


public function setAlteradoEm(): Mensagens 


{ 


$this->alteradoEm = new \DateTime('now'); 
return $this; 


JFF 

* @return \DateTime| null 

*/ 
public function getDeletadoEm(): ?\DateTime 
{ 


return $this->deletadoEm; 


fre 
* @return Mensagens 
as 
public function setDeletadoEm(): Mensagens 


{ 


$this->deletadoEm = new \DateTime('now'); 
return $this; 


[Fe 
* @return Usuarios 
ia 
public function getUsuario(): Usuarios 


{ 


return $this->usuario; 


per 
* @param Usuarios $usuario 
* @return Mensagens 


*/ 


public function setUsuario(Usuarios $usuario): 


{ 
$this->usuario = $usuario; 
return $this; 


Mensagens 


per 
* @return array 
*/ 
public function toArray(): array 


{ 
return (new ClassMethodsHydrator())->extract($this); 


} 


Após definirmos os métodos, perceba que não houve grandes 
diferenças se comparado com as outras entidades que criamos. 
Utilizamos o componente Laminas Hydrator para hidratar/popular e 
também para extrair os dados. Como estamos utilizando interface 
fluente em nossa entidade, todos os métodos setters possuem 
retorno do tipo mensagens , assim podemos utilizar outros métodos da 
classe sem a necessidade de chamar novamente a variável do 
objeto, por exemplo: 


$object->setResposta('Resposta'); 
$object->setAlteradoEm(); 


Através da interface fluente, podemos chamar os métodos da classe 
sem a necessidade de chamar novamente a variável do objeto como 
fizemos no exemplo anterior. Com a interface fluente podemos 
chamar os métodos da seguinte maneira: 


$object->setResposta(' Resposta”) 
->setAlteradoEm() 
->setAtivo(true); 


Com isso, finalmente finalizamos as alterações em nossas 
entidades. Como o código completo dessa classe é grande, você 
poderá vê-lo no GitHub: https://github.com/jhones/projeto- 
mezzio/blob/master/src/App/src/Entity/Mensagens.php/. 


Conclusão 


Chegamos ao final do nosso ultimo capitulo da série de melhoria 
das entidades que foram geradas pelo Doctrine. Durante essa série 
de três capítulos você conheceu O Laminas Hydrator € como esse 
componente do Laminas pode nos ajudar. Além disso, criamos 
diversos métodos, ajustamos os atributos das entidades, definimos 
o tipo de cada atributo e muito mais. 


No próximo capítulo vamos criar os repositórios de cada entidade e 
definir alguns métodos que vamos utilizar em nosso projeto de 
comunicação entre usuários. Então, siga em frente e vamos nessa! 


CAPITULO 11 
Criando repositorios e estendendo a classe 
EntityRepository 


Agora que ja definimos e melhoramos as nossas entidades, 
devemos criar os repositórios. Como você pôde notar, cada entidade 
possui o seu repositório, lembra? Nós definimos cada repositório, 
mas ainda não os criamos. 


Neste capítulo, vamos criar os repositórios contendo alguns 
métodos que utilizaremos futuramente em nossos serviços. 


11.1 Criando o repositório 
TiposUsuarioRepository 


O repositório é como um complemento da entidade e é utilizado 
para realizar as consultas ao banco de dados. É onde ficam os 
métodos que integram as regras de negócio da nossa aplicação. O 
repositório separa da entidade todas as consultas realizadas 
diretamente no banco de dados, deixando a aplicação mais 
organizada. Além disso, podemos utilizar o objeto do repositório em 
outras partes da aplicação. 


Antes de criarmos nosso repositório, devemos criar nosso diretório 
Repository , que é onde ficarão todas as nossas classes de 
repositório. Vamos criá-lo no caminho  src/App/src/ , conforme mostra 
a imagem a seguir: 


projeto-mezzio 


Doctrine 
Entity 
Handler 





Figura 11.1: Criando o diretório Repository 


Dentro deste diretório, vamos criar o repositório propriamente dito. 
Crie uma classe com o nome TiposusuarioRepository conforme 
mostra a imagem a seguir: 


projeto-mezzio 


Doctrine 
Entity 
Handler 


Repository 





Figura 11.2: Criando o repositório TiposUsuarioRepository 


Nosso próximo passo é escrevermos o código em nossa classe. 
Para facilitar o entendimento, primeiro vamos ver o código completo 
da nossa classe e, em seguida, vou explicar o que foi feito na classe 
e qual a finalidade do que estamos fazendo. Veja o código completo 
da classe TiposUsuarioRepository a seguir: 


<?php 
declare(strict types=1); 


namespace App\Repository; 


use Doctrine\ORM\EntityRepository; 


[te 
* Class TiposUsuarioRepository 
* @package App\Repository 
at | 
class TiposUsuarioRepository extends EntityRepository implements 
RepositoryInterface 
{ 
per 
* (return array 
* (throws Exception 


dá 
public function getAll(): array 
{ 
try { 
$data = $this->findAl11(); 
$dataArray = []; 
foreach ($data as $object) { 
$dataArray[] = $object->toArray() ; 
} 
return $dataArray; 
} catch (\Exception $e) { 
throw $e; 
} 
} 
/** 


* @param int $id 
* @return array 
* @throws \Exception 
*/ 
public function getOne(int $id): array 
{ 
try { 
$entity = $this->findOneBy(['id' => $id]); 
return !empty($entity) ? $entity->toArray() : []; 
} catch (\Exception $e) { 


throw $e; 


fr 
* @return array 
* @throws \Exception 
*/ 
public function getAllWithDQL(): array 
{ 
$dql = <<<DQL 
SELECT 
tain, 
t.tipo, 
t.ativo 
FROM App\Entity\TiposUsuario t 
ORDER BY t.tipo ASC 


DQL; 
try { 
$query = $this->getEntityManager()->createQuery($dql); 
$result = $query->getResult(); 
return $result ?? []; 
} catch (\Exception $e) { 
throw $e; 
} 
} 
pr 


* @param int $id 
* @return array 
* @throws \Exception 
*/ 
public function getOneWithDQL(int $id): array 
{ 
$dql = <<<DQL 
SELECT 
tid; 
«TIPO, 
t.ativo 
FROM App\Entity\TiposUsuario t 


WHERE 


t.id = $id 
DQL; 
try { 
$query = $this->getEntityManager()->createQuery($dq1); 
$result = $query->getResult(); 
return $result ?? []; 
} catch (\Exception $e) { 
throw $e; 
} 
} 
} 


A logica que você pode ver na classe TiposUsuarioRepository sera 
basicamente a mesma nas demais classes de repositorios que 
criaremos mais adiante. Para todas, vamos: 


e Ativar o modo estrito do PHP 7; 

e Estender a classe EntityRepository do Doctrine; 

e Implementar a interface RepositoryInterface que foi criada; 
e Entender os métodos implementados. 


A ativação do modo estrito do PHP 7 não será mais explicada daqui 
para a frente, já que nos capítulos anteriores você já aprendeu 
bastante como utilizá-lo, e por todo o projeto será da mesma forma. 


Estendemos a classe EntityRepository em nosso repositório para 
informarmos que a nossa classe deve herdar as características de 
um repositório do Doctrine, ou seja, por meio dessa herança o 
Doctrine vai interpretar que a nossa classe TiposUsuarioRepository é, 
de fato, um repositório válido para o Doctrine, além de poder utilizar 
diversos métodos já criados na classe EntityRepository . 


Logo após estendermos a classe EntityRepository NÓS estamos 
implementando a interface RepositoryInterface , que foi criada para 
que todos os nossos repositórios tenham um padrão em comum que 


sera obrigatório para os nossos exemplos. O código completo da 
nossa interface RepositoryInterface pode ser visto a seguir: 


<?php 
declare(strict types=1); 
namespace App\Repository; 


per 

* Interface RepositoryInterface 
* @package App\Repository 

a 

interface RepositoryInterface 


{ 
per 
* @return array 
A 
public function getAll(): array; 


/** 
* @param int $id 
* @return array 
e 
public function getOne(int $id): array; 


per 
* @return array 
ES 
public function getAllWithDQL(): array; 


[tt 
* @param int $id 
* @return array 
"7 
public function getOneWithDQL(int $id): array; 
} 


Vamos entender qual é a responsabilidade de cada método dessa 
interface: 


e getAll(): array - É responsável por retornar todos os dados de 
uma determinada entidade, incluindo todos os campos que nela 
existirem. E um método utilizado para demonstrar um pouco da 
funcionalidade e as maneiras que temos para executar uma 
mesma ação. Perceba que esse método retorna um array e 
podemos saber essa informação porque o código : array 
informa exatamente isso. 


e getOne(int $id): array - Possui como responsabilidade retornar 
apenas um registro do banco, ou seja, esse método não retorna 
uma coleção de dados como o método getall . Observe que o 
parâmetro int id é obrigatório e por meio dele vamos consultar 
apenas um registro no banco que possuir o id informado. 
Assim como o método geta11 este método retorna um array. 


e getAllWithDQL(): array - O funcionamento desse método é 
semelhante ao do método getall , a única diferença é que no 
método getallwithooL utilizamos a linguagem DQL do Doctrine, 
que nada mais é o próprio SQL adaptado para funcionamento 
com o Doctrine. 


e getOneWithDQL(int $id): array - O funcionamento desse método é 
semelhante ao do getone, tendo apenas uma diferença, sendo 
que neste método será utilizada a linguagem DQL. Tanto o 
método getonewithboL quanto O getallwithboL foram criados para 
demonstrar como fazer consultas utilizando a linguagem DQL. 


Após temos aprendido qual a finalidade de cada método da interface 
RepositoryInterface , Vamos analisar cada método implementado em 
nossa classe TiposUsuarioRepository . 


e getall() - É um método bem simples, que realiza uma consulta 
buscando todos os dados contidos no banco de dados. Perceba 
que estamos utilizando o método s$this->finda11() do Doctrine, 
obtido por meio da herança que fizemos da classe 
EntityRepository , € armazenamos o resultado na variável ¢data 
para que possamos utilizar no foreach . Dentro do foreach , 


temos a variável $object que estamos utilizando, e chamamos 
o método toarray() que está contido dentro da entidade 
TiposUsuario . Estamos armazenando os dados na variável 
$dataArray para que possamos retornar os dados corretamente 
conforme o tipo de retorno esperado pelo método. Como dito, 
esse método busca todos os registros do banco de dados 
incluindo todos os campos. Em aplicações pequenas que não 
possuem tantos dados, não há problemas em utilizá-lo, porém é 
recomendado evitar seu uso, pois nem sempre você quer todos 
os campos de uma determinada entidade e isso também torna 
a consulta mais lenta. 


getOne( int $id) - Também é um método bastante simples e 
possui apenas duas linhas. Este método realiza a busca de 
apenas um registro, e isso é feito por meio do parâmetro id, 
que é do tipo inteiro, caso contrário um erro será lançado. 
Perceba que estamos utilizando o método gthis->findoneBy(['id' 
=> $id]) também disponibilizado por meio da herança com a 
classe EntityRepository . Informamos um array como parâmetro, 
passando como chave o nome id, que é o nome do atributo 
em nossa entidade Tiposusuario, e estamos passando como 
valor o parâmetro $ia. Podemos passar qualquer campo 
existente na entidade como critério de busca no método 
findoneBy , lembrando que o tipo de parâmetro desse método é 
array. O resultado obtido é armazenado em uma variável 
$entity e em seguida chamamos o método toarray logo após o 
método findonesy . O método toarray está contido dentro da 
entidade Tiposusuario . Como o método findoneBy retorna o 
objeto da entidade, então temos acesso a esse método. Por 
fim, estamos retornando o resultado juntamente com uma 
verificação através da condição ternária !empty($entity- 
>toArray()) ? fentity->toArray() : []. 


getallwithDoL() - Este método tem o mesmo objetivo do método 
getAll , porém fizemos uma modificação. Dessa vez, perceba 
que existe sintaxe SQL no método, mas na verdade é o DQL. E 


bem semelhante ao SQL convencional, mas uma das 
diferenças que você pode notar é que, após o From, em vez de 
usarmos o nome da tabela como costumamos fazer, estamos 
utilizando o nome da entidade que criamos com seu 
namespace completo. Perceba que, dessa vez, estamos 
buscando apenas algumas colunas (id, tipo € ativo ) que, no 
nosso caso, são os nomes das propriedades na entidade 
TiposUsuario . Para realizar a consulta, estamos utilizando a 
sequência de métodos do Doctrine gthis->getEntityManager () - 
>createQuery($dq1) , que realiza a consulta do nosso código DQL 
e armazena um objeto query em nossa variável. Logo em 
seguida, chamamos o método ¢query->getResult() que retornará 
o resultado da nossa consulta. Perceba que o método getresult 
pertence ao objeto query , perceba também que utilizamos o 
operador >? de coalescência nula para realizar o retorno do 
método. Esse operador fará com que seja retornado ou o valor 
esperado ou um array vazio. Você pode obter mais informações 
sobre o operador de coalescência nula na documentação oficial 
do PHP no link 
https://www.php.net/manual/pt_BR/migration70.new- 
features.php 


e getOneWithDQL(int $id) - Por fim, este método também possui o 
mesmo funcionamento que o método getone , a diferença é que 
estamos utilizando o DQL. Perceba que não muda muita coisa 
do método getallwithDoL , mas aqui o método getonewithDQL 
recebe um parâmetro que é o id do tipo inteiro e adicionamos 
a cláusula nHERE para informar que queremos buscar apenas 
pelo id. O modo de realizar a consulta e obter o resultado é 
exatamente o mesmo do método getAllwithboL e, assim como 
fizemos, também estamos utilizando o operador de 
coalescência nula para retornar o resultado. 


Com isso, finalizamos a criação do nosso repositório 
TiposUsuarioRepository . Criar um repositório com o Doctrine não é 


uma tarefa complicada, já que ele disponibiliza tudo o que 
precisamos. 


Se você gostaria de conhecer mais sobre o DQL e ver mais 
exemplos, basta você acessar o link https://www.doctrine- 
project.org/projects/doctrine-orm/en/2.7/index.html. O Doctrine 


possui uma excelente documentação, vale a pena dar uma 
conferida na documentação completa, navegue e conheça 
melhor esse incrível ORM. 





11.2 Criando o repositório UsuariosRepository 


Agora que já criamos o repositório TiposUsuarioRepository , Vamos 
criar o repositório UsuariosRepository . Crie uma classe com o nome 
UsuariosRepository Conforme mostra a imagem a seguir: 


projeto-mezzio 
E bin 
config 
EEE 
| public 
| sre 


T 


| Doctrine 
a Entity 
landler 


A Repository 


Repositoryinterface.php 





ository.php 


Figura 11.3: Criando o repositório UsuariosRepository 


Nosso próximo passo é escrever o código em nossa classe. Vamos 
primeiro ver o código completo da nossa classe, mas daqui em 
diante, só serão explicadas as alterações em relação ao anterior, 
pois o funcionamento será basicamente o mesmo. Vamos herdar a 
classe EntityRepository e implementar a interface RepositoryInterface 
e assim será com qualquer outro repositório que criarmos. Veja o 
código completo da classe usuariosRepository a seguir: 


<?php 

declare(strict types=1); 

namespace App\Repository; 

use Doctrine\ORM\EntityRepository; 


ft 
* Class UsuariosRepository 
* @package App\Repository 
+ 
class UsuariosRepository extends EntityRepository implements 
RepositoryInterface 
{ 
Jer 
* @return array 
* (throws Exception 
id 
public function getAll(): array 
{ 


try { 
$data = $this->findAl11(); 
$dataArray = []; 


foreach ($data as $object) { 
$dataArray[] = $object->toArray() ; 


return $dataArray; 
} catch (\Exception $e) { 
throw $e; 


Jer 
* @param int $id 
* @return array 
* @throws \Exception 
*/ 
public function getOne(int $id): array 


try { 

$entity = $this->findOneBy(['id' => $id]); 

return lempty($entity) ? fentity->toArray() : []; 
} catch (\Exception $e) { 

throw $e; 


per 
* @return array 
* (throws \Exception 
*/ 
public function getAllWithDQL(): array 
{ 
$dql = <<<DQL 
SELECT 
u.id, 
.nomeCompleto, 
«ativo, 
«Cpt, 
.dataNascimento, 
.email, 
.ativo, 
«id as tipoUsuario 
FROM App\Entity\Usuarios u 
INNER JOIN u.tipoUsuario t 
ORDER BY u.nomeCompleto ASC 


a E E & E Eis 


DQL; 

try 1 
$query = $this->getEntityManager()->createQuery($dq1); 
$result = $query->getResult(); 
return $result ?? []; 

} catch (\Exception $e) { 
throw $e; 

} 

} 


per 


DQL; 


} 


* @param int $id 
* @return array 
* @throws \Exception 


public function getOneWithDQL(int $id): array 


$dql = <<<DQL 
SELECT 

u.id, 
.nomeCompleto, 
.ativo, 
Ep 
.dataNascimento, 
.email, 
.ativo, 
«id as tipoUsuario 
FROM App\Entity\Usuarios u 
INNER JOIN u.tipoUsuario t 
WHERE 

u.id = $id 


E E E G E E 


try { 
$query = $this->getEntityManager()->createQuery($dq1); 
$result = $query->getResult(); 


return $result ?? []; 
} catch (\Exception $e) { 
throw $e; 


Como você pode notar, o código é bem parecido com o da classe 
TiposUsuarioRepository € ha diferencas em apenas dois métodos, 
sendo eles O getAllwithDQL() € getOneWithDQL(int $id) . A principal 
diferença é que em ambos os métodos você pode notar a utilização 
do INNER JOIN no formato DQL. O Doctrine vai identificar o 
relacionamento por meio do campo tipousuario , que possui as 


annotations (anotações) indicando com qual entidade e coluna do 
banco de dados o atributo se relaciona. 


Não é do escopo deste livro focar no Doctrine, mas sim passar o 
necessário que vamos utilizar em nosso projeto. Caso tenha 
interesse em aprender mais sobre relacionamentos com o 
Doctrine, você pode acessar o link da documentação oficial, que 


contém inúmeros exemplos. Confira em https://www.doctrine- 
project.org/projects/doctrine-orm/en/2.7/reference/association- 
mapping.html. 





11.3 Criando o repositorio MensagensRepository 


Por fim, vamos criar o nosso último repositório, que sera 
responsavel pelas mensagens que um determinado usuario podera 
trocar com outro. Primeiramente, vamos criar nossa classe 
conforme mostra a imagem a seguir: 


projeto-mezzio 


Doctrine 
Entity 
Handler 


Repository 





Figura 11.4: Criando o repositório MensagensRepository 


Com a classe MensagensRepository Criada, vamos ver o código 
completo dela a seguir: 


<?php 

declare(strict_types=1) ; 

namespace App\Repository; 

use Doctrine\ORM\EntityRepository; 


per 


* Class MensagensRepository 
* @package App\Repository 
yd 
class MensagensRepository extends EntityRepository implements 
RepositoryInterface 
{ 
per 
* @return array 
* (throws \Exception 


#7 
public function getAll(): array 
{ 
try { 
$data = $this->findAl1(); 
$dataArray = []; 
foreach ($data as $object) { 
$dataArray[] = $object->toArray(); 
} 
return $dataArray; 
} catch (\Exception $e) { 
throw $e; 
} 
} 
[** 


* @param int $id 
* @return array 
* @throws \Exception 
17 
public function getOne(int $id): array 
{ 
try À 
$entity = $this->findOneBy(['id' => $id]); 
return !empty($entity) ? $entity->toArray() : []; 
} catch (\Exception $e) { 
throw $e; 


per 
* @return array 
* (throws \Exception 
ed 
public function getAllWithDQL(): array 
1 
$dql = <<<DQL 
SELECT 
m.id, 
.mensagem, 
«resposta, 
. dataMensagem, 
«ativo, 
«id as usuario 
FROM App\Entity\Mensagens m 
INNER JOIN m.usuario u 
ORDER BY m.dataMensagem DESC 


C 3333 


DQL; 
try { 
$query = $this->getEntityManager()->createQuery($dql); 
$result = $query->getResult(); 
return $result ?? []; 
} catch (\Exception $e) { 
throw $e; 
} 
} 
j** 


* @param int $id 
* @return array 
* @throws \Exception 
ig é 
public function getOneWithDQL (int $id): array 
{ 
$dql = <<<DQL 
SELECT 
m.id, 
m.mensagem, 
m.resposta, 


m.dataMensagem, 
m.ativo, 
u.id as usuario 
FROM App\Entity\Mensagens m 
INNER JOIN m.usuario u 


WHERE 
m.id = $id 
DQL; 
try { 
$query = $this->getEntityManager()->createQuery($dql); 
$result = $query->getResult(); 
return $result ?? []; 
} catch (\Exception $e) { 
throw $e; 
} 
} 
JEF 


* @param int $userId 
* @return array 
* @throws \Exception 
Ey 
public function getMessagesFromUser(int $userId): array 
{ 

$dql = <<<DQL 

SELECT 
sid, 
.mensagem, 
-resposta, 
. dataMensagem, 
«ativo, 
«id as usuario 
FROM App\Entity\Mensagens m 
INNER JOIN m.usuario u 
WHERE 

u.id = $userId 


C 3 3 33 3 


DQL; 


try { 


$query = $this->getEntityManager()->createQuery($dq1); 
$result = $query->getResult(); 


return $result ?? []; 
} catch (\Exception $e) { 
throw $e; 


} 


Ao analisar o código, você pode perceber que nao ha grandes 
mudangas nos métodos implementados pela interface 
RepositoryInterface . À novidade nessa classe é o método 
getMessagesFromUser , (Ue possui a responsabilidade de recuperar 
todas as mensagens de um determinado usuário através do id de 
usuário passado como parâmetro do método. Os demais códigos 
não sofreram alterações que requerem explicações aprofundadas. 
As alterações foram apenas nos campos a serem retornados, no 
relacionamento e no nome da entidade na qual será realizada a 
consulta. Com isso, chegamos ao final de mais um capítulo. 


Conclusão 


Vimos como criar repositórios utilizando o Doctrine e a linguagem 
DQL, que é o SQL adaptado para o Doctrine. Além disso, criamos 
uma interface que provê métodos comuns entre todas as classes de 
repositórios. Em nosso próximo capítulo, vamos criar e registrar os 
serviços que serão responsáveis por fazer a mediação entre o 
repositório e O middleware . Vale a pena ressaltar que, devido à 
flexibilidade do Mezzio, você pode optar por trabalhar da maneira 
que melhor convém ao projeto, ou como você já esteja habituado. 
Então, siga em frente e vamos nessa. 


CAPITULO 12 
Criando e registrando serviços 


Agora que já temos definidos os nossos repositórios, está na hora 
de criarmos e registrarmos os nossos serviços que serão 
responsáveis por realizar as operações de CRUD (Create, Read, 
Update, Delete) e outros tipos de operações. 


O quE É CRUD? 


CRUD ou Create Read Update Delete, significa: 


Create - Cria um determinado registro; não importa qual tipo, o 
registro deverá ser criado de acordo com a necessidade da sua 
aplicação. 


Read - Leitura/Listagem de dados; obtém os dados 
armazenados no banco de dados para que possam ser tratados 
e/ou apresentados para o usuário. 


Update - Atualiza um determinado registro que já foi inserido 
anteriormente no banco de dados. 


Delete - Deleta/Exclui/Remove/Apaga registros armazenados no 
banco de dados. 





Os serviços serão responsáveis por disponibilizar para toda a 
aplicação meios de poder realizar as operações de CRUD, bem 
como outros tipos de operações que o serviço possa ter 
futuramente. Cada serviço que criarmos em nosso projeto realizará 
as operações de CRUD de acordo com cada repositório que 
criamos no capítulo anterior. Mas não basta criarmos os serviços em 
um diretório e achar que ele já poderá ser utilizado pelo resto da 
aplicação; para que isso seja possível, precisamos registrar cada 


serviço em nosso arquivo de configuração. Mais adiante neste 
capítulo veremos como fazer isso. 


Nas próximas seções veremos cada um desses serviços, então, 
sem perder tempo, vamos nessa. 


12.1 Criando a classe abstrata ServiceAbstract e 
o serviço TiposUsuarioService 


Primeiramente, vamos criar o nosso diretório que deverá conter os 
nossos serviços. Dentro do diretório src/App/src , vamos criar O 
diretório service conforme mostra a imagem a seguir: 
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Figura 12.1: Criando o diretório Service 


Dentro dele, vamos criar o diretório Factory que será responsável 
por conter as Factories dos nossos serviços. Crie o diretório Factory 
conforme mostra a imagem a seguir: 
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Figura 12.2: Criando o diretório Factory 


Com a criação do diretório Factory, podemos realizar a criação do 
nosso primeiro serviço que realizará as operações de acordo com o 
que definirmos nele e com o que já definimos em nossa regra de 
negócio em nosso repositório TiposUsuarioRepository . 


O serviço TiposUsuarioService Será responsável por possuir as 
operações que farão o gerenciamento dos tipos de usuário que 
cadastrarmos em nossa aplicação. É através dele que vamos inserir, 
alterar, listar, deletar os dados pertencentes a esse serviço. 


Então, vamos criar nosso serviço, para isso, dentro do diretório 
Service Crie a Classe TiposUsuarioService Conforme mostra a imagem 
a seguir: 
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Figura 12.3: Criando o serviço TipoUsuarioService 


Logo em seguida vamos criar uma classe abstrata chamada 
ServiceAbstract Que será responsável por conter os métodos 
padrões que poderão ser utilizados por todos os serviços que 


criarmos por meio do conceito de herança, ou seja, estendendo a 
classe abstrata. Seu diretório service deve conter os seguintes 
arquivos até o momento: 
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Figura 12.4: Criando a classe abstrata ServiceAbstract 


Agora vamos ver o código completo de cada uma das classes que 
criamos anteriormente, entender cada método que elas possuem e 
qual é a finalidade de cada um. 


Confira a seguir o código completo da classe abstrata 


ServiceAbstract : 


<?php 
declare(strict types=1); 
namespace App\Service; 


use Doctrine\ORM\EntityManager; 
use Laminas\Hydrator\ClassMethodsHydrator ; 


/** 
* Class ServiceAbstract 
* @package App\Service 
sf 
abstract class ServiceAbstract 
{ 
per 
* @var EntityManager 
dá 


protected fem; 


per 

* @var string 

T 
protected $entity; 


per 
* ServiceAbstract constructor. 
* @param EntityManager $em 
ed 
public function _ construct(EntityManager $em) 


{ 


$this->em = $em; 


pr 
* @return array 
* (throws \Exception 


a é 
public function getAll(): array 
{ 
try { 
$repository = $this->em->getRepository($this->entity) ; 
return frepository->getAl1(); 
} catch (\Exception $e) { 
throw $e; 
} 
} 
[HA 


* (param int $id 
* (return array 
* (throws Exception 


be 
public function getOne(int $id): array 
{ 
try { 
$repository = $this->em->getRepository($this->entity) ; 
return $repository->getOne($id); 
} catch (\Exception $e) { 
throw $e; 
} 
} 
/** 


* @return array 
* @throws \Exception 
ig é 
public function getAllWithDQL(): array 
{ 
try { 
$repository = $this->em->getRepository($this->entity) ; 
return $repository->getAllWithDQL(); 
} catch (\Exception $e) { 
throw $e; 


pes 
* @param int $id 
* @return array 
* (throws \Exception 


*/ 
public function getOneWithDQL(int $id): array 
{ 
try { 
$repository = $this->em->getRepository($this->entity) ; 
return $repository->getOneWithDQL ($id) ; 
} catch (\Exception $e) { 
throw $e; 
} 
} 
pr 


* @param array $data 

* @return mixed 

* @throws \Exception 

+ 
public function insert(array $data): array 
{ 


try { 
$entity = new $this->entity(); 


$classMethods = new ClassMethodsHydrator(); 
$classMethods->hydrate($data, $entity); 


$this->em->persist($entity); 
$this->em->flush(); 


return $entity->toArray(); 


} catch (\Exception $e) { 
throw $e; 


per 


* @param array $data 
* @return array 
* @throws \Exception 
vy 
public function update(array $data): array 
{ 
try { 


$entity = $this->em->getReference($this->entity, $data['id']); 


$classMethods = new ClassMethodsHydrator(); 
$classMethods->hydrate($data, $entity); 


$this->em->persist($entity); 
$this->em->flush(); 


return $entity->toArray(); 
} catch (\Exception $e) { 
throw $e; 


per 
* @param int $id 
* @throws \Exception 


*7 
public function delete(int $id): void 
{ 
try { 
$entity = $this->em->getReference($this->entity, $id); 
$this->em->remove($entity); 
$this->em->flush(); 
} catch (\Exception $e) { 
throw $e; 
} 
} 


Vamos entender o que significa o código dessa classe. A primeira 
coisa a notar é a palavra-chave abstract antes da definição do 
nome da classe. A palavra abstract está informando que a classe 


que estamos criando é uma classe abstrata, mas o que isso 
significa? Significa que a classe não pode ser instanciada e para ter 
acesso aos métodos e atributos dela, deve-se estendê-la/herdá-la 
com o uso da palavra extends , isso é o que chamamos de herança. 
Veremos o funcionamento da herança na prática em nossos 
serviços. 


Caso não tenha ficado clara a explicação sobre a classe abstrata, 
veja o exemplo a seguir para fixar o conhecimento: 


<?php 


abstract class AbstractService 


{ 
public $entity = 'Entidade'; 
public $em = 'EntityManager'; 


class Service 


{ 
private $entity; 
private $em; 


public function __construct() 


{ 
$abstractService = new AbstractService(); 
$this->entity = $abstractService->entiy; 
$this->em = $abstractService->em; 

} 

public function getEntity() 

{ 
return $this->entity; 

} 

public function getEm() 

{ 
return $this->em; 

} 


$service = new Service(); 


Tente reproduzir esse exemplo e você receberá um erro fatal, 
informando que não é possível instanciar a classe AbstractService , 
isso porque ela é uma classe abstrata e não permite criar um objeto 
utilizando a palavra new. O único modo de conseguir utilizar os 
atributos public $entity € public $em que está definida na classe 
AbstractService é através da herança. Veja o código a seguir, que 
torna isso possível: 


<?php 


abstract class AbstractService 


{ 
public $entity = 'Entidade'; 
public $em = 'EntityManager'; 
} 
class Service extends AbstractService 
{ 
public function getEntity() 
{ 
return $this->entity; 
} 
public function getEm() 
{ 
return $this->em; 
} 
} 


$service = new Service(); 
echo $service->getEntity(); 
echo $service->getEm(); 
//Ou ainda... 

echo $service->entity; 

echo $service->em; 


Veja que por meio da herança com a palavra extends conseguimos 
ter acesso aos atributos public $entity € public $em e ainda 
conseguimos manipulá-los em nossa classe concreta service. 
Pense em classe abstrata como sendo algo que não se pode ver, 
você sabe que existe mas não pode tocar, no caso, não pode 
instanciar - é bem por aí. 


Outro ponto importante a ser observado é que definimos os atributos 
como protected OU protegido em português, mas os métodos da 
classe como public ou público. Mas o que isso significa? Significa 
que somente as classes que herdam/estendem a classe abstrata 
podem ter acesso aos métodos e atributos. O método construtor 

_ construct recebe como atributo um objeto EntityManager do 
Doctrine. 


e protected $em - Essa propriedade será injetada por meio do 
parámetro do método construtor que injetará o objeto 
EntityManager para que possa ser utilizado pelos métodos da 
classe. 


e protected $entity - Essa propriedade receberá o nome completo 
de uma entidade, ou seja, o nome da entidade incluindo o seu 


namespace . 


e getAl1(): array - Obtém do repositório todos os dados 
pertencentes a uma determinada entidade, esse método 
retornará todos os dados de acordo com o que foi definido no 
método dentro do repositório. 


e getOne(int $id): array - Obtém apenas um registro de acordo 
com o que foi definido no método dentro do repositório. O 
registro será obtido através do id que deverá ser informado 
como parámetro do método. Vocé pode estar se perguntando: 
mas qual repositório? A resposta é simples, o repositório da 
entidade que vamos definir em cada servico. 


e getAllWithDQL(): array - Assim como o método getal1 , retorna 
todos os dados de uma determinada entidade, porém a 


diferença é que no repositório é utilizada a linguagem poL , esse 
método está presente para que o leitor possa entender a 
diferença entre utilizar a linguagem po. e os métodos 
fornecidos pelo Doctrine. 


getOneWithDQL( int $id): array - Também funciona como o método 
getone e a sua diferença está no método definido no repositório, 
que utiliza a linguagem DeL para obter os dados do registro. 
Esse método também está presente para que o leitor possa 
entender a diferença entre utilizar a linguagem bo e os 
métodos fornecidos pelo Doctrine. 


insert(array $data): array - Esse método é responsável por 
realizar a inserção de um registro no banco de dados. Um ponto 
importantíssimo a ser observado é a utilização do componente 
já conhecido, Laminas Hydrator, que realizará a atribuição dos 
dados de forma mais performática e eficaz, como já vimos 
anteriormente. Esse método recebe como parâmetro um array 
de dados que deve conter o nome de cada atributo que foi 
definida na entidade, possibilitando que o Laminas Hydrator 
realize a atribuição automática dos dados. 


update( array $data): array - Realiza a atualização dos dados de 
um determinado registro de uma determinada entidade. Esse 
método recebe um array de dados como parâmetro e dentro 
desse conjunto de dados deve existir uma chave chamada id 
contendo o id do registro a ser alterado. É através dessa 
chave que a alteração dos dados será possível. Outro ponto a 
ser observado é a utilização do método getReference , que é 
disponibilizado pelo objeto EntityManager . Esse método é 
responsável por recuperar as informações da entidade por meio 
do Proxy , que é gravado la no diretório de cache . Isso faz com 
que a consulta se torne mais ágil ao realizar a busca pela 
informação desejada. 


delete(int $id): void - Realiza a exclusão de um determinado 
registro do banco de dados de uma determinada entidade. Esse 


método recebe como parâmetro um id, que deve ser 
informado no momento de sua utilização. Assim como no 
método update , aqui também utilizamos o método getReference 
do objeto EntityManager . Um outro ponto importante a ser 
observado é que o tipo de retorno desse método é void ou 
seja, ele não retorna absolutamente nada, apenas executa a 
sua lógica e finaliza o processamento sem retorno algum. 


Todos os métodos definidos em nossa classe abstrata poderão ser 
acessados pelas nossas classes de serviços por meio da herança, 
como já falamos. Agora que conhecemos a nossa classe 
Serviceabstract que será a base para todas as demais classes de 
serviços que criamos, está na hora de conhecermos a nossa 
primeira classe de serviço. 


Confira a seguir o código completo da classe Tiposusuarioservice : 


<?php 

declare(strict types=1); 
namespace App\Service; 

use App\Entity\TiposUsuario; 


per 
* Class TiposUsuarioService 
* @package App\Service 
= 
class TiposUsuarioService extends ServiceAbstract 


{ 


protected $entity = TiposUsuario::class; 


} 


Jhones, é só isso? Sim, meu amigo, o código desse e dos demais 
serviços serão simples como esse, com poucas linhas de código. 
Isso porque criamos uma classe abstrata que servirá como base 
para todos os serviços que criarmos, e como herdamos a classe 


base, teremos todos os métodos e atributos disponíveis em nossa 
classe concreta TiposUsuarioService . 


No código da nossa classe TiposUsuarioService , perceba que 
estamos utilizando extends ServiceAbstract que indica que estamos 
herdando a classe serviceabstract e por meio dessa herança 
teremos acesso a todos os métodos que criamos na classe abstrata 
e todos os atributos. 


Perceba que estamos utilizando o atributo protected fentity , que 
definimos lá na nossa classe abstrata, e estamos atribuindo a ela o 
nome completo da nossa entidade TiposUsuario por meio do código 
TiposUsuario::class . Essa é a entidade que será correspondente ao 
servico TiposUsuarioService . 


Com isso, finalizamos a criacáo do nosso primeiro servico que herda 
as características da nossa classe abstrata. Na próxima secáo 
vamos criar O Servico UsuariosService . 


12.2 Criando o Servico UsuariosService 


Antes de mais nada, esse servico será responsável pelas operações 
destinadas aos usuários da nossa aplicacáo. Assim como o anterior, 
esse servico também realizará as operações de CRUD pertencentes 
ao repositório UsuariosRepository e outras que possam surgir ou que 
você deseje criar. 


Então, vamos criar O serviço Usuariosservice em nosso diretório 
Service, assim como fizemos anteriormente com o servico 
TiposUsuarioService , conforme mostra a imagem a seguir: 
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Figura 12.5: Criando o serviço UsuariosService 


Após a criação do serviço, vamos ver o código completo a seguir: 


<?php 


declare(strict types=1); 
namespace App\Service; 


use App\Entity\TiposUsuario; 
use App\Entity\Usuarios; 
use Laminas\Hydrator\ClassMethodsHydrator ; 


per 
* Class UsuariosService 
* @package App\Service 
*/ 
class UsuariosService extends ServiceAbstract 


{ 


protected $entity = Usuarios::class; 


per 

* @param array $data 

* @return mixed 

* (throws \Exception 

*/ 

public function insert(array $data): array 
{ 


try { 
$entity = new $this->entity(); 


$userType = $this->em->getReference(TiposUsuario::class, 
$data[ 'tipoUsuario']); 

$data[ 'tipoUsuario'] = $userType; 

$data[ 'dataNascimento'] = new 
\DateTime($data[ 'dataNascimento' 1); 


$classMethods = new ClassMethodsHydrator(); 
$classMethods->hydrate($data, fentity); 


$this->em->persist(fentity); 
$this->em->flush(); 


return $entity->toArray(); 
} catch (\Exception $e) { 
throw $e; 


per 

* @param array $data 

* @return array 

* @throws \Exception 

*/ 

public function update(array $data): array 
{ 


try { 
$entity = $this->em->getReference($this->entity, $data['id']); 


if (!empty($data['tipoUsuario'])) { 
$userType = $this->em->getReference(TiposUsuario::class, 
$data['tipoUsuario']); 
$data['tipoUsuario'] = $userType; 


if (!empty($data['dataNascimento'])) { 
$data['dataNascimento'] = new 
\DateTime($data['dataNascimento']); 


} 


$classMethods = new ClassMethodsHydrator(); 
$classMethods->hydrate($data, $entity); 


$this->em->persist($entity); 
$this->em->flush(); 


return $entity->toArray(); 
} catch (\Exception $e) { 
throw $e; 


} 


Vamos entender por que esse serviço é um pouco maior do que o 
Serviço TiposUsuarioService . Assim como anteriormente, perceba que 


estamos herdando a classe serviceAbstract que ja provê diversos 
métodos que poderemos e vamos utilizar em nossa aplicação. 


Perceba que os únicos métodos que estamos sobrescrevendo são o 
insert(array $data) € O update(array $data). Mas você sabe o motivo 
dessa sobrescrita, já que ambos estão em nossa classe abstrata? É 
bem simples: o método presente em nossa classe abstrata é 
genérico e mais simples, mas serve perfeitamente para serviços que 
não necessitam realizar a inserção ou alteração de dados que 
possuam algum tipo de dependência que deva ser processada 
antes, para que se tenha o efeito esperado, como o relacionamento. 
Em nosso serviço temos uma dependência que é obter o registro do 
tipo de usuário que deve ser informado no momento da 
inserção/alteração do registro. Se omitirmos esse dado ao 
realizarmos a inserção ocorrerá erro, pois esse dado é obrigatório. 


Por exemplo, perceba que quando criamos a entidade usuarios 
definimos um relacionamento com a entidade TiposUsuario . Dessa 
forma, em nosso serviço, isso também deve ser refletido para que, 
no momento em que realizarmos a inserção ou alteração do 
registro, não ocorram erros informando que o campo tipo usuario id 
no banco de dados não pode ser nulo. 


Em nosso serviço, isso é feito através do código guserType = $this- 
>em->getReference(TiposUsuario::class, $data[ 'tipoUsuario']), QUe diz 
que estamos buscando, em nosso cache de proxies do Doctrine, o 
tipo de usuário correspondente ao valor passado no corpo da 
requisição. Por exemplo, se passarmos o valor 1, será com base 
nesse valor que o Doctrine fará a busca no cache e retornará um 
objeto correspondente à entidade que passamos como primeiro 
parâmetro. Por fim, o resultado obtido será armazenado na variável 
$userType . Em todo esse processo, o Doctrine não realizará 
nenhuma consulta no banco de dados, tornando o procedimento 
muito mais eficiente. 


Por fim, com o código $data['tipousuario'] = $userType , estamos 
passando o resultado obtido, armazenado na variável $userType, 


para o nosso atributo tipousuario , que foi definida em nossa 
entidade Usuarios . É importante ser exatamente o mesmo nome, 
porque o Laminas Hydrator fará a atribuição dos dados com base no 
nome dos atributos da entidade, caso o nome do atributo esteja 
incorreto, a atribuição não será realizada, então atente-se bem a 
ISSO. 


Logo em seguida, temos o código $data[ 'dataNascimento'] = new 
\DateTime($data['dataNascimento']) que é responsável por realizar a 
atribuição da data de nascimento informada na chave dataNascimento 
do array de dados. Se você for olhar na entidade, verá que esse 
atributo é do tipo DateTime , e estamos setando-a aqui porque 
precisamos converter a string da data de nascimento que será 
informada no corpo da requisição no formato DateTime . 


O código $userType = $this->em->getReference(TipoUsuario::class, 
$data[ 'tipoUsuario']) presente no método insert(array $data) € O 
trecho $data[ 'dataNascimento'] = new ADateTime($data[ 'dataNascimento']) 
também estão presentes no método update(array $data) e possuem 
exatamente o mesmo funcionamento, por esse motivo não serão 
explicados novamente. 


No método update(array $data), a novidade é o código $entity = 
$this->em->getReference($this->entity, $data['id']) , que possui O 
mesmo funcionamento descrito anteriormente, porém, nesse caso, 
estamos buscando através do parâmetro $data['id'] contido na 
entidade usuarios O registro correspondente ao id informado para 
realizarmos a alteração. 


Apesar de o código ser um pouco maior do que o do serviço 
TiposUsuarioService , Seu funcionamento é bastante simples. Agora 
que finalizamos a construção do nosso serviço UsuariosService , Na 
próxima seção vamos criar O nosso último serviço, O 
MensagensService , que terá um código bem semelhante ao nosso 
serviço de usuários. 


12.3 Criando o serviço MensagensService 


Esse serviço será responsável por armazenar em nosso banco de 
dados as mensagens que os usuários enviarão entre si para que se 
possa obter um histórico de mensagens trocadas entre eles. Assim 
como os serviços anteriores, este também realizará as operações 
de CRUD pertencentes ao repositório mensagensRepository e outros 
tipos de operações que possam surgir ou as que você desejar criar. 


Como de costume, antes de mais nada vamos criar o nosso serviço 
MensagensService em nosso diretório service, conforme mostra a 
imagem a seguir: 
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Figura 12.6: Criando o serviço MensagensService 
Vamos analisar o código completo a seguir: 
<?php 
declare(strict_types=1); 


namespace App\Service; 


use App\Entity\Mensagens; 
use App\Entity\Usuarios; 
use Laminas\Hydrator\ClassMethodsHydrator ; 


per 
* Class MensagensService 
* @package App\Service 
*/ 
class MensagensService extends ServiceAbstract 


{ 


protected $entity = Mensagens: :class; 


per 

* @param array $data 

* @return array 

* @throws \Exception 

*/ 

public function insert(array $data): array 
{ 

try { 
$entity = new $this->entity(); 


$user = $this->em->getReference(Usuarios::class, 
$data[ 'usuario']); 

$data[ 'usuario'] = $user; 

$data[ 'dataMensagem'] = new \DateTime('now' ); 


$classMethods = new ClassMethodsHydrator(); 
$classMethods->hydrate($data, fentity); 


$this->em->persist(fentity); 
$this->em->flush(); 


return $entity->toArray(); 
} catch (\Exception $e) { 
throw $e; 


/** 


* @param array $data 


* @return array 

* @throws \Exception 

*/ 

public function update(array $data): array 


{ 


try { 
$entity = $this->em->getReference($this->entity, $data['id']); 


if (!empty($data['usuario'])) { 
$user = $this->em->getReference(Usuarios::class, 
$data['usuario']); 
$data['usuario'] = $user; 


$classMethods = new ClassMethodsHydrator(); 
$classMethods->hydrate($data, $entity); 


$this->em->persist($entity); 
$this->em->flush(); 


return $entity->toArray(); 
} catch (\Exception $e) { 
throw $e; 


} 


Perceba que o código é muito semelhante ao do serviço 
UsuariosService porque nesse caso também fizemos a sobrescrita 
dos métodos insert(array $data) € update(array $data). Desse modo, 
não serão explicados novamente os dois métodos sobrescritos, 
porém perceba que atribuímos ao nosso atributo protected $entity a 
entidade Mensagens: :class, ficando da seguinte maneira: protected 
fentity = Mensagens: : class . Isso foi feito porque nosso serviço 
MensagensService trabalhará com a entidade correspondente, que é a 
entidade mensagens . Cada serviço possui a sua entidade 
correspondente, logo não estaria correto chamarmos a entidade 
desse serviço como sendo Usuarios OU TiposUsuario pois não são 
pertencentes a esse serviço. 


Nosso trabalho foi poupado graças a nossa classe abstrata. Imagine 
ter que escrever para cada serviço os mesmos métodos alterando 
apenas a entidade? Seria uma tarefa cansativa e com duplicidade 
de código! Sempre que puder, utilize uma classe base e ou uma 
interface, isso fará com que sua aplicação seja bem mais flexível. 


Agora que criamos todos os nossos serviços, devemos criar as suas 
Factories (fábricas) que serão responsáveis por retornar o objeto do 
serviço em questão por meio do contêiner de injeção de 
dependência. 


12.4 Criando a Factory 
TiposUsuarioServiceFactory 


Essa Factory vai retornar uma instância do serviço 
TiposUsuarioService que poderá ser utilizada por toda a aplicação. 


Vamos criar nossa Factory TiposUsuarioServiceFactory dentro do 
nosso diretório service/Factory conforme mostra a imagem a seguir: 
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Figura 12.7: Criando a Factory TiposUsuarioServiceFactory 


Os códigos das nossas Factories serão bem simples, como você 
pode ver a seguir: 


<?php 
declare(strict types=1); 
namespace App\Service\Factory; 


use App\Service\TiposUsuarioService; 
use Doctrine\ORM\EntityManager; 


use Psr\Container\ContainerInterface; 


per 

* Class TiposUsuarioServiceFactory 
* @package App\Service\Factory 

*/ 

class TiposUsuarioServiceFactory 


{ 
JEF 
* @param ContainerInterface $container 
* @return TiposUsuarioService 
*/ 
public function _ invoke(ContainerInterface fcontainer): 
TiposUsuarioService 


{ 
$em = $container->get(EntityManager::class); 
return new TiposUsuarioService($em); 


} 


Como você pode ver, só estamos utilizando o método _ invoke _ 
assim como já fizemos anteriormente para configurarmos o 
Doctrine. Nesse método, estamos passando como parâmetro 
apenas a interface ContainerInterface , que é a responsável por 
prover os métodos que são utilizados pelo contêiner de injeção de 
dependências. 


Definimos o tipo de retorno do método como sendo um objeto do 
tipo TiposUsuarioService €, no momento da criação desse objeto, 
estamos passando um objeto Entitymanager que foi obtido através do 
código $em = $container->get(EntityManager::class) . Esse objeto é 
aquele que definimos quando estávamos criando a configuração do 
Doctrine, lembra? Como o registramos em nosso arquivo 
ConfigProvider.php , podemos utilizá-lo de qualquer lugar da 
aplicação, desde que consigamos utilizar o contêiner de injeção de 
dependência. 


Não tem muito segredo, não é mesmo? Da mesma maneira faremos 
com os demais serviços e o código será muito semelhante, 


mudando apenas o objeto a ser retornado pela Factory. 


12.5 Criando a Factory UsuariosServiceFactory 


Essa Factory é responsável por retornar uma instância do serviço 
UsuariosService . Crie a Factory UsuariosServiceFactory dentro do 
nosso diretório service/Factory conforme mostra a imagem a seguir: 
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Figura 12.8: Criando a Factory UsuariosServiceFactory 


Confira a seguir o código completo dessa Factory: 


<?php 
declare(strict_types=1) ; 
namespace App\Service\Factory; 


use App\Service\UsuariosService; 


use Doctrine\ORM\EntityManager ; 
use Psr\Container\ContainerInterface; 


per 
* Class UsuariosServiceFactory 
* @package App\Service\Factory 


Ef 
class UsuariosServiceFactory 
1 
per 
* @param ContainerInterface $container 
* @return UsuariosService 
*/ 
public function __invoke(ContainerInterface $container): 
UsuariosService 
{ 
$em = $container->get(EntityManager::class); 
return new UsuariosService($em); 
} 
} 


Como podemos ver, o código é pequeno e semelhante ao da 
Factory anterior, a única diferença é o objeto a ser retornado, que 
nesse caso é uma instância do serviço UsuariosService . 


12.6 Criando a Factory MensagensServiceFactory 


Essa Factory será responsável por retornar uma instância do serviço 
MensagensService . Crie a Factory MensagensServiceFactory em nosso 
diretório service/Factory conforme mostra a imagem a seguir: 
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Figura 12.9: Criando a Factory MensagensServiceFactory 


Vamos ver a seguir codigo completo da nossa Factory 
MensagensServiceFactory : 


<?php 
declare(strict_types=1) ; 
namespace App\Service\Factory; 


use App\Service\MensagensService; 


use Doctrine\ORM\EntityManager ; 
use Psr\Container\ContainerInterface; 


per 
* Class MensagensServiceFactory 
* @package App\Service\Factory 


Ef 
class MensagensServiceFactory 
1 
per 
* @param ContainerInterface $container 
* @return MensagensService 
*/ 
public function __invoke(ContainerInterface $container): 
MensagensService 
{ 
$em = $container->get(EntityManager::class); 
return new MensagensService($em); 
} 
} 


Perceba que novamente não houve grandes alterações e que o 
código é bem semelhante aos anteriores. Qual é a única diferença? 
Se você pensou que é apenas o objeto que é retornado pela 
Factory, você acertou! Nessa Factory estamos retornando o objeto 
do serviço MensagensService . 


Com isso, finalizamos a criação da nossas Factories, mas ainda não 
acabamos. Para finalizarmos o capítulo, falta registrarmos nossos 
serviços em nosso arquivo de configuração ConfigProvider.php € é 
exatamente isso que faremos na próxima seção. 


12.7 Registrando os serviços 


Devemos registrar nossos serviços para que eles possam funcionar 
corretamente e estejam disponíveis em toda a aplicação. 


Para isso, abra o seu arquivo src/App/src/ConfigProvider.php € 
localize o método getDependencies() . No array que é retornado pelo 
método, localize a chave Factories e vamos registrar nossos 
serviços com nossas Factories. 


Confira a seguir o código completo do método getDependencies() 
contendo o registro dos nossos servicos: 


<?php 
per 
* Returns the container dependencies 
El 
public function getDependencies() : array 
{ 
return [ 


'invokables' => [ 
Handler\PingHandler::class => Handler\PingHandler::class, 
], 
"Factories' => [ 
Handler\HomePageHandler::class => 
Handler\HomePageHandlerFactory::class, 
Handler\TestDoctrineConnectionHandler::class => 
Handler\Factory\TestDoctrineConnectionHandlerFactory::class, 


//Registrando Serviços 
Service\TipoUsuarioService::class => 
Service\Factory\TipoUsuarioServiceFactory::class, 
Service\UsuarioService::class => 
Service\Factory\UsuarioServiceFactory::class, 
Service\MensagemService::class => 
Service\Factory\MensagemServiceFactory::class 
], 
1; 
} 


Perceba que nao é complicado registrar os serviços. Um ponto 
importante a ser mencionado é que não necessariamente você 
precisa definir o nome do registro como sendo o nome completo da 
classe, por exemplo Service\TiposUsuarioService::class . Se você 
quiser chamar apenas de tipos usuario service OU UM outro nome 


qualquer de sua escolha, você pode fazer isso sem problemas, só 
não esqueça de chamar o nome correto no momento em que você 
for utilizar o serviço através do contêiner de injeção de dependência, 
combinado? 


Conclusão 


Chegamos ao final de mais um capítulo no qual vimos exemplos de 
como criarmos serviços, Factories e registrar nossos serviços para 
que possam ser utilizados por toda a aplicação através do contêiner 
de injeção de dependência. Vimos aqui como uma classe base pode 
nos ajudar, aumentando a reusabilidade do código e evitando a 
duplicidade. Vale ressaltar que existem inúmeras maneiras de se 
fazer isso, então cabe a você se aprofundar, criar sua própria lógica 
e decidir a melhor maneira de fazer em sua aplicação. 


No próximo capítulo, vamos criar e registrar nossos 
handlers/middlewares/actions (qualquer um dos termos está correto e 
pode ser utilizado), então, siga em frente e vamos nessa! 


CAPITULO 13 

Criando e registrando Handlers de tipos de 
usuario 

Agora que criamos e registramos os nossos serviços, temos que 
criar os nossos Handlers/Middlewares que serão responsáveis por 


receber as requisições enviadas pela aplicação cliente, fazer o 
tratamento adequado e retornar uma resposta para o cliente. 


Esse repasse será feito até que um Handler/Middleware seja capaz 
de tratar adequadamente a requisição com seus dados. 


Nas próximas seções, veremos como criar cada Handler/Middleware 
da nossa aplicação, como serão muitos Handlers/Middlewares o 
assunto será dividido em três capítulos. 


O QUE É HANDLER/MIDDLEWARE? 


Handler/Middleware são manipuladores que possuem como 


responsabilidade realizar o tratamento de alguma informação, ou 
repassá-la para frente, caso não consiga realizar o tratamento 
adequado. 





Antes de prosseguirmos, será necessário instalar o componente 
Laminas Json em nossa aplicação, porque ele será responsável por 
decodificar a string em JSON convertendo-a em array e vice- 
versa. 


O QUE E LAMINAS JSON? 


É um componente do Laminas responsável por realizar a 


codificação de dados em formato JSON e também a 
decodificação do JSON em outros formatos, como o array, por 
exemplo. 





Para clonar o componente, execute o comando a seguir na raiz da 
sua aplicação: 


composer require laminas/laminas-json 


Após executar o comando anterior, o componente Laminas Json 
será instalado e injetado automaticamente no arquivo de 
configuração. 


Após a instalação do componente Laminas Json, podemos seguir 
em frente para criarmos os Handlers. 


13.1 Criando o Handler 
TiposUsuarioListarHandler 


O primeiro Handler/Middleware que vamos criar é o 
TiposUsuarioListarHandler , QUE sera responsavel por listar todos os 
tipos de usuario disponiveis em nosso banco de dados. 


Antes de criarmos o nosso Handler propriamente dito, vamos criar 
uma classe abstrata que sera responsavel por conter atributos e 
métodos padrões que servirão como base para todos os nossos 
handlers subsequentes. Para isso, vamos criar a nossa classe 
HandlerAbstract em nosso diretório src/App/src/Handler , conforme 
mostra a imagem a seguir: 
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Figura 13.1: Criando a classe abstrata HandlerAbstract 


O código desse Handler é bastante simples e você pode conferir a 
seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler; 


use Laminas\Diactoros\Response\J sonResponse; 
use Psr\Container\ContainerInterface; 


pr 
* Class HandlerAbstract 


* @package App\Handler 
vy 
abstract class HandlerAbstract 
{ 
JET 
* @var ContainerInterface 
id 
protected $container; 


per 
* HandlerAbstract constructor. 
* @param ContainerInterface $container 
+y 
public function _ construct(ContainerInterface $container) 


1 


$this->container = $container; 


pr 
* @param array $response 
* @param int $statusCode 
* @return JsonResponse 
vy 
protected function successResponse(array $response, int $statusCode = 
200): JsonResponse 


{ 
return new JsonResponse([ 
'data' => $response 
], $statusCode); 
} 
pr 


* (param \Exception $e 
* (param string $message 
* (param int $statusCode 
* (return JsonResponse 
"7 
protected function errorResponse(\Exception $e, string $message, int 
$statusCode = 400): JsonResponse 
1 


return new JsonResponse( [ 


'error' => true, 

'status code'=> $statusCode, 

'message' => $message, 

"message description’ => $e->getMessage() 
1, $statusCode) ; 


} 


Como você pode ver, nossa classe abstrata não é complexa e 
possui apenas um atributo protected $container do tipo 
Psr\Container\ContainerInterface , que será responsável por 
armazenar o objeto do nosso contêiner de injeção de dependência. 
Essa propriedade será populada no momento em que o construtor 
da classe for chamado. 


Veja que o Nosso método __construct(ContainerInterface $container) 
recebe como parâmetro um objeto do tipo 
Psr\Container\ContainerInterface € realiza a atribuição desse objeto 
ao atributo $this->container . Isso é feito para que nossos Handlers 
possam utilizar os serviços registrados em nosso contêiner de 
injeção de dependência. Você verá como será utilizado mais adiante 
neste capítulo. 


Temos dois métodos protected (protegidos) que serão acessados 
através da herança quando criarmos a classe concreta. O método 
successResponse(array fresponse, int $statusCode = 200): JsonResponse é 
responsável por retornar uma estrutura de resposta de sucesso 
padrão contendo os dados informados no parâmetro $response . O 
parâmetro $statuscode contém o código de resposta HTTP. Por 
padrão, o valor assumido será o 29 , mas podemos informar 
qualquer um outro código, como 201, 206 etc. Perceba que o 
parâmetro $statuscode é passado como segundo argumento da 
classe 3sonResponse , que, ao enviar a resposta em formato 3son, 
também enviará o código de resposta. Se não informarmos um 
código de resposta, a classe JsonResponse assumirá 
automaticamente que o código de resposta é 200 (oK) indicando 
que não houve erros com a requisição. Você verá nas próximas 


seções como utilizar outro status de resposta HTTP, afinal, existe 
um status correto para cada tipo de resposta. 


O outro método protected (protegido) que temos em nossa classe 
abstrata é o errorResponse(\Exception $e, string $message, int 
$statusCode = 400): JsonResponse . Ele é responsável por retornar uma 
estrutura de resposta de erro padrão. Perceba que é bem 
semelhante ao método successResponse , com a diferença de que no 
método errorresponse estamos recebendo três parâmetros. O 
primeiro parámetro, $e, é uma exceção, ou seja, um objeto do tipo 
Exception , que será passado para o método quando ocorrer alguma 
exceção durante o processamento na classe concreta. O segundo 
parâmetro $message é Uma mensagem de erro que vamos informar 
na classe concreta. O terceiro e último parâmetro gstatuscode possui 
a mesma funcionalidade que o do método successResponse com a 
diferença de que o código de reposta padrão é o «ee, que indica 
algum erro na requisição. Assim como o método successResponse , O 
tipo de retorno também é do tipo 3sonresponse contendo um array de 
dados que será enviado como resposta e convertido em json. 


Agora que temos nossa classe abstrata que proverá métodos e 
atributos em comum para os nossos Handlers utilizarem, vamos 
criar nossa primeira classe de Handler. Como de costume, vamos 
criar um diretório dentro de src/App/src/Handler chamado 
TiposUsuario , QUe armazenará todas as nossas classes de Handlers 
de tipos de usuário. Em seguida, dentro do diretório que acabamos 
de criar, crie uma classe chamada TiposUsuarioListarHandler , 
conforme mostra a imagem a seguir: 
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Figura 13.2: Criando o Handler TiposUsuarioListarHandler 


Agora que vocé ja criou a classe de Handler, vamos analisar o 
código a seguir para você entender o funcionamento. Veja o código 
do Handler TiposUsuarioListarHandler a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\TiposUsuario; 


use App\Handler\HandlerAbstract; 
use App\Service\TiposUsuarioService; 


use Psr\Http\Message\ResponselInterface; 
use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 


per 
* Class TiposUsuarioListarHandler 
* @package App\Handler\TiposUsuario 


*/ 


class TiposUsuarioListarHandler extends HandlerAbstract implements 


RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
EA 
public function handle(ServerRequestInterface $request): 
ResponseInterface 
{ 
try { 


$service = $this->container->get(TiposUsuarioService::class); 


$resultWithDQL = $service->getAll1(); 
$resultWithoutDQL = $service->getAl1WithDQL(); 


$response = $this->successResponse([ 
'result with dql' => $resultWithDQL, 
'result without dql' => $resultWithoutDQL 
1); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
"Erro ao listar os tipos de usuário", 
400 


)3 


return $response; 


} 


A primeira coisa a notar nesse código é a herança da nossa classe 


Handlerabstract e a implementação da interface 


RequestHandlerInterface , que são realizados pelo código extends 


HandlerAbstract implements RequestHandlerInterface . 


Como dito anteriormente, nossa classe Handlerabstract possui 
atributos e métodos que são comuns entre todos os Handlers que 
vamos criar. A implementação da interface RequesHandlerInterface 
proverá o método handle(ServerRequestInterface $request) , NO qual 
vamos trabalhar. Esse método é responsável por receber a 
requisição e realizar ou não o tratamento adequado das 
informações, retornando ou não uma resposta para o cliente, em 
formato Json . Perceba que o tipo de retorno esperado pelo método 
handle(ServerRequestInterface $request) é um objeto do tipo 
ResponseInterface , OU seja, tem que ser um objeto que tenha 
implementado a interface ResponseInterface do pacote 
Psr\Http\Message . 


Dentro do método handle(ServerRequestInterface $request) temos 
poucas linhas de código contendo uma pequena lógica para 
tratamento de erros através do bloco try-catch . Perceba que nosso 
código todo está dentro do bloco try, o que quer dizer que o PHP 
vai tentar executar o código e, se não houver erro, retornará 
corretamente os dados, caso contrário, o processamento passará 
automaticamente para dentro do bloco catch para capturar o erro 
ocorrido durante a execução. 


Dentro do bloco try a primeira parte a se notar é a utilização do 
código $service = $this->container->get(TiposUsuarioService::class) . 
Nele, estamos utilizando o atributo gcontainer , que foi herdado de 
nossa classe abstrata Handlerabstract , bem como o método get 
presente no objeto de nosso atributo. Esse método é o responsável 
por obter o nosso serviço TiposUsuarioService registrado em nosso 
contêiner de injeção de dependência em nosso arquivo 
ConfigProvider , € armazenar o objeto do nosso serviço na variável 


gservice. 


Os próximos trechos a se observar são $resultWithDQL = $service- 
>getAll() € fresultWithoutDQL = $service->getAll1WithDQL() . Nesses 


codigos, estamos realizando a consulta para obter todos os tipos de 
usuários utilizando os métodos getall() € getallWithoutDoL de 
nossos serviços. Estamos armazenando o resultado obtido nas 
variáveis $resultwithDQL € $resultWithoutDoL respectivamente. 


Em seguida estamos criando a estrutura de resposta de sucesso: 


$response = $this->successResponse([ 
“result with dql' => $resultWithDQL, 
"result without dql' => $resultWithoutDQL 
1); 


Perceba que estamos chamando o método $this->successResponse 
que criamos em nossa classe abstrata Handlerabstract e estamos 
passando um array de dados da resposta, lembrando que esse 
método retornará um objeto 3sonResponse . 


Caso ocorra algum erro durante o processamento da requisicáo, 
vamos ter o seguinte modelo de resposta: 


$response = $this->errorResponse( 
$e, 
“Erro ao listar os tipos de usuário", 
400 


)3 


Perceba que mais uma vez estamos chamando um metodo que 
criamos em nossa classe abstrata Handlerabstract . O método $this- 
>errorResponse fará a montagem da resposta padrão para casos de 
erro na requisição e este método também retorna um objeto do tipo 


JsonResponse . 


Como dito anteriormente, temos que retornar um objeto do tipo 
Psr\Http\Message\ResponseInterface . Se vocé analisar a classe 
JsonResponse QUe estamos instanciando no momento do retorno de 
nossos métodos successResponse € errorResponse definidos dentro da 
classe abstrata Handlerabstract , vera que ela estende a classe 
Laminas\Diactoros\Response , QUe por si implementa a interface 


Psr\Http\Message\ResponseInterface , permitindo que ela seja valida 
para ser utilizada como retorno do método. 


Finalizamos aqui a criação do nosso Handler 
TiposUsuarioListarHandler . Como vocé pôde ver, não foi complicado, 
nem complexo e o código ficou bem pequeno. Na próxima seção 
vamos criar a Factory do nosso Handler. 


Criando a Factory TiposUsuarioListarHandlerFactory 


Assim como temos feito com todos os nossos serviços, também 
devemos criar nossas Factories e registrar em nosso contêiner de 
injeção de dependência, para que o Mezzio possa interpretar e 
realizar o processamento. 


Crie a classe de Factory TiposUsuarioListarHandlerFactory , conforme 
mostra a imagem a seguir: 
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Figura 13.3: Criando a Factory TiposUsuarioListarHandlerFactory 


Após a criacáo da Factory, veja como é seu código completo a 
seguir: 


<?php 
declare(strict_types=1) ; 
namespace App\Handler\Factory; 


use App\Handler\TiposUsuario\TiposUsuarioListarHandler; 
use Psr\Container\ContainerInterface; 


[HA 

* Class TiposUsuarioListarHandlerFactory 
* @package App\Handler\TiposUsuario 

e 


class TiposUsuarioListarHandlerFactory 


per 
* @param ContainerInterface fcontainer 
* (return TiposUsuarioListarHandler 
*7 
public function __invoke(ContainerInterface $container): 
TiposUsuarioListarHandler 


{ 


return new TiposUsuarioListarHandler($container); 


} 


O código da nossa Factory é bem simples e, inclusive, todas as 
Factories que criarmos terão um código simples como esse. O único 
objetivo dessa Factory é retornar a instância da classe 
TiposUsuarioListarHandler , que será utilizada pela aplicação. Esse 
objeto retornado é o que conseguimos utilizar quando realizamos a 
chamada através do contêiner de injeção de dependência e é assim 
com todas as demais Factories. É importante ressaltar que estamos 
passando como parâmetro da nossa classe TiposUsuarioListarHandler 
o objeto do tipo containerInterface contido no parâmetro $container . 


Lembre-se de que nossos Handlers estenderão a classe abstrata 
HandlerAbstract que contém o método construtor e é exatamente 
nele que informamos que, ao construirmos um objeto de Handler, 
deverá ser passado como parâmetro um objeto do tipo 


ContainerInterface. 


Nosso próximo passo é registrar o nosso Handler em nosso arquivo 
de configuração configProvider e é isso que faremos na próxima 
seção. 


Registrando o Handler TipoUsuarioListarHandler 


Como já fizemos com nossos serviços anteriormente, devemos 
registrar nossos Handlers também, caso contrário, o Mezzio não 
saberá que eles existem e quando chamarmos uma rota ele não 
conseguirá encontrar. Vamos registrá-lo para que isso não ocorra. 


Para registrarmos é bem simples, abra o arquivo 
src/App/src/ConfigProvider.php € localize o método getDependencies() . 
Logo abaixo do registro Handler\TestDoctrineConnectionHandler: :class 
que fizemos no capítulo 6, digite o código de registro a seguir: 


Handler\TiposUsuario\TiposUsuarioListarHandler::class => 
HandleriFactoryNTiposUsuarioListarHandlerFactory:: class, 


É somente isso, esse pequeno trecho de código que você acabou 
de digitar já é responsável por realizar o registro do nosso Handler. 


Se estiver dessa maneira, parabéns, você está no caminho certo. 
Caso não esteja, reveja os passos com calma e tente novamente. 


Na próxima seção vamos continuar a criação dos nossos Handlers 
de tipos de usuários. 


13.2 Criando o Handler 
TiposUsuarioListarUmHandler 


Agora vamos criar o Handler que será responsável por listar apenas 
um registro de tipo de usuário. Isso será possível com o parâmetro 
id que vamos informar no URL. É por meio dele que vamos buscar 
no banco de dados o registro equivalente ao id informado. 


Em seu diretório src/App/src/Handler/TiposUsuario , crie uma classe 
chamada TiposusuarioListarUmHandler , conforme mostra a imagem a 
seguir: 
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Figura 13.4: Criando o Handler TiposUsuarioListarUmHandler 


Após a criação da classe de Handler, vamos analisar o código 
completo dela a seguir e entender o que ela faz: 


<?php 

declare(strict types=1); 

namespace App\Handler\TiposUsuario; 
use App\Handler\HandlerAbstract; 


use App\Service\TiposUsuarioService; 
use Psr\Http\Message\ResponseInterface; 


use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 


per 
* Class TiposUsuarioListarUmHandler 
* @package App\Handler\TiposUsuario 
*/ 
class TiposUsuarioListarUmHandler extends HandlerAbstract implements 
RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
a 
public function handle(ServerRequestInterface $request): 
ResponseInterface 


{ 
$id = (int)frequest->getAttribute('id'); 


try { 
$service = $this->container->get(TiposUsuarioService::class); 


$resultWithDQL = $service->getOne($id); 
$resultWithoutDQL = $service->getOneWithDQL ($id) ; 


$response = $this->successResponse( [ 
"message' => 'Nenhum registro encontrado" 
], 404); 


if (!empty($resultWithDQL) && !empty($resultWithoutDQL)) { 
$response = $this->successResponse([ 
'result with dql' => $resultWithDQL, 
'result without dql' => $resultWithoutDQL 
1); 
} 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
"Erro ao listar o tipo de usuáro com o id ' . $id, 
400 


)3 


return $response; 


} 


Como você pode ver, a classe é bem semelhante à nossa classe de 
Handler TiposUsuarioListarHandler , e ela faz praticamente a mesma 
coisa, porém, aqui temos algumas diferenças dentro do nosso 
método handle(ServerRequestInterface $request) . 


O primeiro trecho a ser observado é o código $id = (int)$request- 
>getattribute('id') , que tem como responsabilidade recuperar O id 
que foi informado como parâmetro do URL, que vamos definir na 
rota mais à frente neste livro. 


Em seguida, o código transformará o valor do parâmetro obtido do 
URL em um número inteiro por meio do cast (int) e armazenar o 
valor na variável $id para que possamos utilizá-la. 


É importante informar que esse método pode ter algumas melhorias 
para garantir que o valor informado realmente é um número e um 
número inteiro. Isso pode ser feito por você mesmo como um 
simples exercício. 


Os próximos trechos de códigos a serem observados são os que 
estão dentro do bloco try que são O $resultWithDQL = $service- 
>getOne($id) € fresultWithoutDQL = $service->getOneWithDQL ($id). 
Perceba que estamos passando como parâmetro dos métodos a 
variável $id e consequentemente estamos armazenando o 
resultado dos métodos em suas variáveis $resultwithDQL € 
$resultWithoutDQL , respectivamente. 


Em seguida, estamos definindo uma resposta com código: 


$response = $this->successResponse([ 
'message' => 'Nenhum registro encontrado’ 
], 404); 


O código de status 484 indicará que o resultado não foi encontrado. 
Essa resposta não está dentro de um bloco condicional, porque 
automaticamente assumiremos que caso o ID não seja encontrado 
essa resposta será enviada para O client. 


Em seguida, temos uma condição com a qual verificamos se as 
variáveis contendo os resultados não são vazias. Caso não sejam 
vazias, montamos uma resposta chamando o método 

successResponse da nossa classe abstrata passando o array de dados 
da resposta e, como não informamos o segundo parâmetro do 
método, ele assumirá que o código de status é o 2ee indicando que 
o processamento da requisição foi bem-sucedido. Caso a condição 
não seja satisfeita, então a resposta a ser enviada será a que 
definimos anteriormente com o código de status 404. 


Agora que criamos nosso Handler TiposUsuarioListarUmHandler , 
vamos criar sua Factory na próxima seção. 


Criando a Factory TiposUsuarioListarUmHandlerFactory 


Esta Factory que vamos criar agora será responsável por retornar a 
instância do nosso Handler TiposusuarioListarUmHandler . Então, crie a 
Factory TiposUsuarioListarUmHandlerFactory dentro do nosso diretório 
src/App/src/Handler/Factory , Conforme mostra a imagem a seguir: 
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Figura 13.5: Criando a Factory TiposUsuarioListarUmHandlerFactory 


Após a criação da Factory, vamos ver como é seu código completo 
a seguir: 


<?php 


Assim como a nossa Factory TiposUsuarioListarHandlerFactory , a 
nossa Factory TiposUsuarioListarUmHandlerFactory é bem simples e 
tem o objetivo de retornar uma instancia da classe 
TiposUsuarioListarUmHandler , que poderemos utilizar por meio do 
nosso contêiner de injeção de dependência. Mas, para que isso seja 
possível, devemos registrar nosso Handler, assim como fizemos 
anteriormente com os serviços e com o Handler 
TiposUsuarioListarHandler , € é exatamente isso que faremos na 
próxima seção. 


Registrando o Handler TiposUsuarioListarUmHandler 


Para registrarmos, abra o arquivo src/App/src/ConfigProvider.php € 
localize o método getDependencies() . Logo abaixo do registro 
Handler\TiposUsuario\TiposUsuarioListarHandler::class QUe fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler\TiposUsuario\TiposUsuarioListarUmHandler::class => 
Handler\Factory\TiposUsuarioListarUmHandlerFactory::class, 


Com isso, nosso Handler foi devidamente registrado e ja podera ser 
utilizado pela nossa aplicação. 


Finalizamos a criação de mais um Handler. Na próxima seção 
vamos criar o Handler TiposusuarioCriarHandler que será responsável 
pela criação dos registros de tipos de usuário. 


13.3 Criando o Handler TiposUsuarioCriarHandler 


Este Handler será responsável por realizar a criação dos registros 
de tipos de usuário. Ele fará a inserção dos dados no banco de 
dados por meio do método post do HTTP que vamos definir no 
momento da criação das rotas da aplicação. 


Em seu diretório src/App/src/Handler/TiposUsuario , crie uma classe 
chamada TiposUsuarioCriarHandler , conforme mostra a imagem a 
seguir: 


projeto-mezzio 
bin 
config 
data 
public 
src 
App 
Y B src 
- Doctrine 
> Bm Entity 
Y Bm Handler 
Factory 





TiposUsuario 


Figura 13.6: Criando o Handler TiposUsuarioCriarHandler 


Após a criação da classe, vamos analisar seu código completo e 
entender o que ela faz: 


<?php 

declare(strict types=1); 

namespace App\Handler\TiposUsuario; 
use App\Handler\HandlerAbstract; 


use App\Service\TiposUsuarioService; 
use Psr\Http\Message\ResponseInterface; 


use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Laminas\Json\Json; 


per 
* Class TiposUsuarioCriarHandler 
* @package App\Handler\TiposUsuario 
*/ 
class TiposUsuarioCriarHandler extends HandlerAbstract implements 
RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
EA 
public function handle(ServerRequestInterface $request): 
ResponseInterface 
{ 


try { 
$data = Json: :decode($request ->getBody()->getContents(), 


JSON OBJECT AS ARRAY); 


$service = $this->container->get(TiposUsuarioService::class); 
$userType = $service->insert($data); 


$response = $this->successResponse($userType, 201); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
"Erro ao criar o tipo de usuário!', 
400 


)3 


return $response; 


} 


Como você pode ver, o código é bem simples e temos em nosso 
método handle(ServerRequestInterface $request) O código $data = 
Json: :decode($request ->getBody()->getContents(), JSON OBJECT AS ARRAY) . 


Ele é responsável por obter os dados que foram enviados por meio 
do corpo da requisição post em formato JSON, transformá-los em 

array € armazená-los na variável $data para que possamos utilizá- 
los. Vale lembrar que todo o nosso código está dentro de um bloco 

try-catch para tratarmos os possíveis erros que ocorrerem durante 
o processamento da requisição. 


Em seguida, temos o código $userType = $service->insert($data) , QUe 
é responsável por realizar a inserção dos dados por meio do método 
insert($data) do nosso serviço. Esse método recebe como 
parâmetro os dados obtidos da requisição, que foram convertidos 
em array e estão armazenados na variável $data. 


Por fim, montamos a resposta chamando o método successResponse 
passando para ele o tipo de usuário que foi inserido, já em formato 
de array e não de objeto. Com isso, estamos informando que os 
dados a serem exibidos como resposta serão os dados do tipo de 
usuário que acabou de ser criado. Observe também o código de 
resposta 291, que indica que um determinado registro foi criado. 


E caso ocorra algum erro durante todo esse processo, estamos 
montando a resposta chamando o nosso já conhecido método 


errorResponse . 


Na próxima seção vamos criar a Factory do nosso Handler. 
Criando a Factory TiposUsuarioCriarHandlerFactory 


Esta Factory sera responsavel por retornar a instancia do nosso 
Handler TiposUsuarioCriarHandler . Então, crie a Factory 
TiposUsuarioCriarHandlerFactory dentro do nosso diretório 
src/App/src/Handler/Factory conforme mostra a imagem a seguir: 


¥ livro-zend-expressive 
bin 


config 


oCriarHandlerFactory.php 





Figura 13.7: Criando a Factory TiposUsuarioCriarHandlerFactory 
Após a criação da Factory, vamos ver como é seu código completo: 
<?php 
declare(strict types=1); 
namespace App\Handler\Factory; 


use App\Handler\TiposUsuario\TiposUsuarioCriarHandler; 
use PsriContaineriContainerInterface; 


per 
* Class TiposUsuarioCriarHandlerFactory 
* @package App\Handler\Factory 
Er 


class TiposUsuarioCriarHandlerFactory 


{ 
[+ 
* @param ContainerInterface $container 
* (return TiposUsuarioCriarHandler 
ie 
public function _ invoke(ContainerInterface $container): 
TiposUsuarioCriarHandler 


{ 


return new TiposUsuarioCriarHandler($container); 


} 


Até aqui nenhum segredo, a Factory está retornando a instância do 
Handler TiposUsuarioCriarHandler para que possamos utilizar em 
nossa aplicação, assim como fizemos com as demais. 


Na próxima seção faremos o registro do nosso Handler 
TiposUsuarioCriarHandler para que o Mezzio o reconheça e possa 
utilizá-lo. 


Registrando o Handler TiposUsuarioCriarHandler 


Assim como fizemos anteriormente, vamos registrar o nosso 
Handler. Abra o arquivo src/App/src/ConfigProvider.php e localize o 
método getDependencies() . Logo abaixo do registro 
Handler\TiposUsuario\TiposUsuarioListarUmHandler::class que fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler\TiposUsuario\TiposUsuarioCriarHandler::class => 
Handler\Factory\TiposUsuarioCriarHandlerFactory::class, 


Com isso, nosso Handler foi devidamente registrado e ja podera ser 
utilizado pela nossa aplicação. 


Finalizamos a criação de mais um Handler. Na próxima seção 
vamos criar o Handler tiposUsuarioAlterarHandler que sera 
responsável pela alteração de todos os dados de um determinado 
tipo de usuário. 


13.4 Criando o Handler 
TiposUsuarioAlterarHandler 


Nosso próximo passo é criar o Handler que fará a alteração dos 
dados de um determinado tipo de usuário. Isso será feito pelo id 
que será informado como parâmetro da requisição. Para esse caso, 
nós vamos utilizar o método put do HTTP. 


Em seu diretório src/App/src/Handler/TiposUsuario , Crie uma classe 
chamada TiposusuarioalterarHandler , conforme mostra a imagem a 
seguir: 
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Figura 13.8: Criando o Handler TiposUsuarioAlterarHandler 


Após a criação da classe, vamos analisar seu código completo a 
seguir e entender o que ela faz: 


<?php 
declare(strict types=1); 
namespace App\Handler\TiposUsuario; 


use App\Handler\HandlerAbstract; 

use App\Service\TiposUsuarioService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Laminas\Json\J son; 


per 
* Class TiposUsuarioAlterarHandler 
* @package App\Handler\TiposUsuario 
Ef 
class TiposUsuarioAlterarHandler extends HandlerAbstract implements 
RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
od 
public function handle(ServerRequestInterface $request): 
ResponseInterface 
{ 
try { 
$data = Json::decode($request->getBody()->getContents(), 
JSON_OBJECT_AS ARRAY); 
$data['id'] = (int)$request->getAttribute(‘id'); 


$service = $this->container->get(TiposUsuarioService::class); 
$userType = $service->update($data) ; 


$response = $this->successResponse($userType) ; 
} catch (\Exception $e) { 
$response = $this->errorResponse( 


$e, 
'Erro ao alterar os dados do tipo de usuário!', 
400 


); 


return $response; 


} 


O código dessa classe também é bastante simples e, como no 
Handler TiposUsuarioCriarHandler , temos O código $data = 

Json: :decode($request->getBody()->getContents(), JSON_OBJECT_AS_ARRAY) , 
que possui exatamente a mesma função já explicada anteriormente. 


Em seguida, temos o codigo $data['id'] = (int)$request- 
>getAttribute('id'), que obtém o id informado como parâmetro da 
requisição, converte o valor obtido em um número inteiro, e 
armazena o resultado através da criação da chave id dentro do 
array contido na variável ¿data . Esse campo estará disponível 
dentro do array e poderá ser utilizado pelo método update($data) do 
serviço de tipo de usuário. 


Temos também o código $userType = $service->update($data) , QUe é 
responsável por realizar a alteração dos dados do tipo de usuário. 
Veja que estamos passando o array de dados contido na variável 
$data COMO parâmetro do método update($data) para que ele possa 
fazer a alteração dos dados corretamente. 


Por fim, ele armazena o resultado da alteração dos dados na 
variável $userType para que possamos utilizá-la no retorno do 
método. 


A resposta a ser enviada é bem semelhante à do Handler 
TiposUsuarioCriarHandler contendo o resultado da alteração feita 
anteriormente e que foi armazenado na variável $userType . 


Na próxima seção faremos a criação da Factory do Handler 


TiposUsuarioAlterarHandler . 


Criando a Factory TiposUsuarioAlterarHandlerFactory 


Esta Factory sera responsavel por retornar a instancia do nosso 
Handler TiposUsuarioAlterarHandler . Então, crie a Factory 
TiposUsuarioAlterarHandlerFactory dentro do nosso diretório 
src/App/src/Handler/Factory conforme mostra a imagem a seguir: 
projeto-mezzio 

bin 

config 

data 

public 


Doctrine 
Entity 
| Handler 
E Factory 





© TestDoctrineConnectionHandlerFactory.php 


Figura 13.9: Criando a Factory TiposUsuarioAlterarHandlerFactory 


Após a criação da Factory, vamos ver como é seu código completo 
a seguir: 


<?php 


declare(strict types=1); 


namespace App\Handler\Factory; 


use App\Handler\TiposUsuario\TiposUsuarioAlterarHandler; 
use Psr\Container\ContainerInterface; 


per 

* Class TiposUsuarioAlterarHandlerFactory 
* @package App\Handler\Factory 

e 
class TiposUsuarioAlterarHandlerFactory 


{ 
[+ 
* (param ContainerInterface $container 
* (return TiposUsuarioAlterarHandler 
*/ 
public function __invoke(ContainerInterface $container): 
TiposUsuarioAlterarHandler 


{ 


return new TiposUsuarioAlterarHandler($container); 


} 


Assim como as demais Factories dos nossos Handlers, esta 
também não possui nenhum segredo. Seu objetivo é retornar a 
instância do nosso Handler TiposUsuarioAlterarHandler para a nossa 
aplicação. 


Na próxima seção, vamos fazer o registro do nosso Handler para 
que o Mezzio o reconheça e possa ser utilizado pela nossa 
aplicação. 


Registrando o Handler TiposUsuarioAlterarHandler 


Assim como fizemos anteriormente, vamos registrar o nosso 
Handler, para registrarmos, abra o arquivo 
src/App/src/ConfigProvider.php € localize o método getDependencies() . 
Logo abaixo do registro 


Handler\TiposUsuario\TipoUsuarioCriarHandler::class que fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler\TiposUsuario\TiposUsuarioAlterarHandler::class => 
Handler\Factory\TiposUsuarioAlterarHandlerFactory::class, 


Com isso, nosso Handler foi devidamente registrado e ja podera ser 
utilizado pela nossa aplicação. 


Finalizamos a criação de mais um Handler. Na próxima seção 
vamos criar o Handler TiposusuarioDeletarHandler que será 
responsável pela exclusão de um determinado tipo de usuário 
através do id informado no parâmetro da requisição. 


13.5 Criando o Handler 
TiposUsuarioDeletarHandler 


Agora vamos criar o último Handler de tipos de usuário, que será 
responsável por realizar a exclusão de um determinado tipo de 
usuário. Isso será feito através do id que será informado como 
parâmetro da requisição. Para esse caso, nós vamos utilizar o 
método DELETE do HTTP. Você verá isso quando formos definir as 
rotas da aplicação, não se preocupe. 


Em seu diretório src/App/src/Handler/TiposUsuario , crie uma classe 
chamada TiposUsuarioDeletarHandler , conforme mostra a imagem a 
seguir: 


projeto-mezzio 
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Factory 
TiposUsuario 
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Figura 13.10: Criando o Handler TiposUsuarioDeletarHandler 


Após a criacáo da classe, vamos analisar seu código completo a 
seguir e entender o que ela faz: 


<?php 
declare(strict types=1); 


namespace App\Handler\TiposUsuario; 


use App\Handler\HandlerAbstract; 

use App\Service\TiposUsuarioService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 


per 

* Class TiposUsuarioDeletarHandler 

* @package App\Handler\TiposUsuario 

ni 

class TiposUsuarioDeletarHandler extends HandlerAbstract implements 
RequestHandlerInterface 


{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
*/ 
public function handle(ServerRequestInterface $request): 
ResponseInterface 
{ 
try { 
$id = (int)$request->getAttribute('id'); 
$service = $this->container->get(TiposUsuarioService::class); 
$service->delete($id); 
$response = $this->successResponse([ 
'message' => 'O tipo de usuário foi deletado com sucesso!" 
1); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
"Erro ao deletar o tipo de usuário!', 
400 
)5 
} 
return $response; 
} 


O código demonstrado anteriormente é bem semelhante aos 
anteriores. Como você pode ver, temos o código $id = (int)$request- 
>getattribute('id') Que possui como responsabilidade obter o id 
informado como parâmetro da requisição. Estamos convertendo o 
valor obtido em inteiro e armazenando-o na variável $id para ser 
utilizado posteriormente. 


Em seguida, temos o código gservice->delete($id) , que é 
responsável por deletar o registro através do id que foi passado 
como parámetro do método delete($id) . 


Por fim, estamos montando a resposta de sucesso informando que 
tudo ocorreu perfeitamente bem com o processamento da 
requisição para deletar o tipo de usuário. E caso ocorra algum erro 
com o processamento estamos montando a resposta de erro dentro 
do bloco catch. 


Agora que finalizamos a criação do nosso último Handler de tipos de 
usuário, vamos criar sua Factory também e é isso que faremos na 
próxima seção. 


Criando a Factory TiposUsuarioDeletarHandlerFactory 


Esta Factory será responsável por retornar a instância do nosso 
Handler TiposUsuarioDeletarHandler . Então, crie a Factory 
TiposUsuarioDeletarHandlerFactory dentro do nosso diretório 
src/App/src/Handler/Factory Conforme mostra a imagem a seguir: 


projeto-mezzio 


bin 


config 
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ões 
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Figura 13.11: Criando a Factory TiposUsuarioDeletarHandlerFactory 


Após a criação da Factory, vamos ver como é seu código completo 
a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory; 


use App\Handler\TiposUsuario\TiposUsuarioDeletarHandler; 
use Psr\Container\ContainerInterface; 


pes 


* Class TiposUsuarioDeletarHandlerFactory 


* @package App\Handler\Factory 
“f 
class TiposUsuarioDeletarHandlerFactory 


{ 


JEF 
* @param ContainerInterface $container 
* @return TiposUsuarioDeletarHandler 
*/ 
public function __invoke(ContainerInterface $container): 
TiposUsuarioDeletarHandler 


{ 


return new TiposUsuarioDeletarHandler($container) ; 


} 


Assim como as demais Factories que criamos neste capitulo, essa 
não teria função diferente: ela possui a responsabilidade de retornar 
a instância do Handler TiposUsuarioDeletarHandler . 


Vale lembrar que todas as Factories que criamos neste capítulo 
necessitam da passagem do parâmetro gcontainer do tipo 
Psr\Container\ContainerInterface NO momento da criação da instância. 


Esse parâmetro foi definido no construtor da classe Handlerabstract 
e, consequentemente, todos os Handlers que herdaram essa classe 
possuem o método construtor que recebe como parâmetro o 


$container . 


Na próxima secáo vamos fazer o registro do Handler para que o 
Mezzio possa reconhecé-lo e para que nossa aplicacáo possa 
utilizá-lo. 


Registrando o Handler TiposUsuarioDeletarHandler 


Assim como fizemos anteriormente, vamos registrar o nosso 
Handler. Abra o arquivo src/App/src/ConfigProvider.php e localize o 
método getDependencies() . Logo abaixo do registro 
Handler\TiposUsuario\TiposUsuarioAlterarHandler::class QUE fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler\TiposUsuario\TiposUsuarioDeletarHandler::class => 
Handler\Factory\TiposUsuarioDeletarHandlerFactory::class, 


O código completo de seu método getDependencies() deve ser 
parecido com o demonstrado a seguir: 


public function getDependencies() : array 
{ 
return [ 
“invokables' => [ 
Handler\PingHandler::class => Handler\PingHandler::class, 
1, 
'factories' => [ 
Handler\HomePageHandler::class => 
Handler\HomePageHandlerFactory::class, 
Handler\TestDoctrineConnectionHandler::class => 
Handler\Factory\TestDoctrineConnectionHandlerFactory::class, 
Handler\TiposUsuario\TiposUsuarioListarHandler::class => 
Handler\Factory\TiposUsuarioListarHandlerFactory::class, 
Handler\TiposUsuario\TiposUsuarioListarUmHandler::class => 
Handler\Factory\TiposUsuarioListarUmHandlerFactory::class, 
Handler\TiposUsuario\TiposUsuarioCriarHandler::class => 
Handler\Factory\TiposUsuarioCriarHandlerFactory::class, 
Handler\TiposUsuario\TiposUsuarioAlterarHandler::class => 
Handler\Factory\TiposUsuarioAlterarHandlerFactory::class, 
Handler\TiposUsuario\TiposUsuarioDeletarHandler::class => 
Handler\Factory\TiposUsuarioDeletarHandlerFactory::class, 


//Registrando Serviços 
Service\TiposUsuarioService::class => 
Service\Factory\TiposUsuarioServiceFactory::class, 
Service\UsuariosService::class => 
Service\Factory\UsuariosServiceFactory::class, 
Service\MensagensService::class => 
Service\Factory\MensagensServiceFactory: :class 
], 
1; 
} 


Com isso, nosso Handler foi devidamente registrado e ja podera ser 
utilizado pela nossa aplicação. Finalizamos a criação do último 


Handler de tipo de usuario. 


Conclusao 


Chegamos ao fim de mais um capitulo, no qual definimos os 
Handlers de tipos de usuário, ou seja, os Handlers que farão a 
listagem, criação, exclusão e alteração dos registros. Também 
fizemos a criação das Factories dos nossos Handlers e realizamos 
também o registro de cada um dos Handlers que criamos. 


Em nosso próximo capítulo, daremos continuidade na criação de 
Handlers e vamos criar os Handlers de usuários, então siga em 
frente sem desanimar e vamos nessa! 


CAPITULO 14 
Criando e registrando Handlers de Usuarios 


No capítulo anterior, criamos os Handlers de tipos de usuário, sendo 
que cada Handler é responsável por uma determinada ação, como 
listar todos os registros, listar apenas um registro, criar um registro, 
alterar um registro e deletar um registro. 


Para os Handler de usuários não será diferente, faremos como no 
capítulo anterior e não terá segredos porque o processo de criação 
e registro é exatamente o mesmo. Nas próximas seções veremos 
cada Handler de usuário que criaremos para a nossa aplicação, 
onde serão explicados apenas os pontos mais importantes, pois já 
conhecemos o processo de criação. 


14.1 Criando o Handler UsuariosListarHandler 


Primeiramente, vamos criar o Handler que será responsável por 
listar os usuários cadastrados no banco de dados. Para isso, crie o 
diretório Usuarios dentro de src/App/src/Handler e, em seguida, crie a 
classe UsuariosListarHandler dentro do diretório Usuarios , conforme 
mostra a imagem a seguir: 


projeto-mezzio 
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Figura 14.1: Criando o Handler UsuariosListarHandler 


Vamos ver como é o código completo desse Handler a seguir: 


<?php 
declare(strict_types=1) ; 
namespace App\Handler\Usuarios; 


use App\Handler\HandlerAbstract; 


use App\Service\UsuariosService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 


per 


* Class UsuariosListarHandler 
* @package App\Handler\Usuarios 


*/ 


class UsuariosListarHandler extends HandlerAbstract implements 
RequestHandlerInterface 


{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
public function handle(ServerRequestInterface $request): 
ResponseInterface 
{ 
try { 
$service = $this->container->get(UsuariosService 
$resultWithDQL = $service->getAl1l(); 
$resultWithoutDQL = $service->getAl1WithDQL(); 
$response = $this->successResponse( [ 
'result with dql' => $resultWithDQL, 
'result without dql' => $resultWithoutDQL 
1); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
"Erro ao listar os usuários!', 
400 
)5 
} 
return $response; 
} 


::class); 


Como você pode ver, o código é bem semelhante ao da classe 
TiposUsuarioListarHandler . À única diferença é que a nossa classe 
UsuariosListarHandler realizará a listagem dos usuários, e não dos 
tipos de usuário existentes. Isso pode ser visto no código gservice = 
$this->container->get (UsuariosService::class) , em que estamos 
buscando em nosso contêiner de injeção de dependências o serviço 
de usuários, que será responsável, nesse caso, por listar os 
usuários cadastrados em nosso banco de dados. 


O retorno do método é exatamente o mesmo contido na classe 
TiposUsuarioListarHandler , inclusive as chaves definidas para exibição 
dos resultados. A diferença é que nesse caso estaremos retornando 
os usuários. 


Agora que criamos nosso Handler para listar os usuários, na 
próxima seção vamos criar a Factory do nosso Handler. 


Criando a Factory UsuariosListarHandlerFactory 


Como você já sabe, as Factories são responsáveis por realizar a 
criação/instância de um objeto sem exibir a lógica para o código que 
realiza a chamada. Devemos criar a Factory porque nossos 
Handlers possuem uma dependência que é um objeto do tipo 
Psr\Container\ContainerInterface definido no construtor da nossa 
classe abstrata Handlerabstract . 


Para criar a nossa Factory, crie o diretório usuarios dentro do 
diretório src/App/src/Handler/Factory e, em seguida, a classe 
UsuariosListarHandlerFactory , conforme mostra a imagem a seguir: 
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Figura 14.2: Criando a Factory UsuariosListarHandlerFactory 


Após a criacáo da Factory, vamos ver como será seu código a 
seguir: 


<?php 
declare(strict_types=1) ; 


namespace App\Handler\Factory; 


use App\Handler\Usuarios\UsuariosListarHandler; 
use Psr\Container\ContainerInterface; 


ft 
* Class UsuariosListarHandler 
* @package App\Handler\Factory 
e 
class UsuariosListarHandlerFactory 


{ 
per 
* @param ContainerInterface $container 
* (return UsuariosListarHandler 
E 
public function _ invoke(ContainerInterface $container): 
UsuariosListarHandler 


{ 


return new UsuariosListarHandler($container); 


} 


Nenhuma novidade na criação dessa Factory. Lembre-se, a Factory 
deve apenas retornar a instância de uma classe que, nesse caso, é 
a instância da classe usuariosListarHandler . 


Na próxima seção faremos o registro do nosso Handler em nosso 
arquivo de configuração, como fizemos no capítulo anterior. 


Registrando o Handler UsuariosListarHandler 


Para registrarmos é bem simples, abra o arquivo 
src/App/src/ConfigProvider.php € localize o método getDependencies() . 
Logo abaixo do registro 
Handler\TiposUsuario\TiposUsuarioDeletarHandler::class que fizemos no 
capítulo anterior, coloque o código de registro a seguir: 


HandlerYUsuariosMUsuariosListarHandler::class => 
Handler\Factory\UsuariosListarHandlerFactory::class, 


Na próxima seção vamos criar o Handler responsável por listar 
apenas um usuário através do id informado no parâmetro da URL. 


14.2 Criando o Handler UsuariosListarUmHandler 


Vamos criar o Handler que será responsável por realizar a listagem 
de apenas um usuário através do id que deverá ser informado 
como parâmetro da URL. Esse parâmetro será definido no momento 
em que criarmos as rotas da nossa aplicação. 


Crie a classe UsuariosListarHandler dentro do diretório 
src/App/src/Handler/Usuarios , Conforme mostra a imagem a seguir: 
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Figura 14.3: Criando o Handler UsuariosListarUmHandler 


Após a criação da classe, vamos ver como é seu código completo a 
seguir: 


<?php 
declare(strict types=1); 


namespace App\Handler\Usuarios; 


use App\Handler\HandlerAbstract; 

use App\Service\UsuariosService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 


per 
* Class UsuariosListarUmHandler 
* @package App\Handler\Usuarios 
*/ 
class UsuariosListarUmHandler extends HandlerAbstract implements 
RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
*/ 
public function handle(ServerRequestInterface $request): 
ResponseInterface 


{ 
$id = (int)$request->getAttribute('id'); 


try { 
$service = $this->container->get(UsuariosService::class); 


$resultWithDQL = $service->getOne($id); 
$resultWithoutDQL = $service->getOneWithDQL ($id) ; 


$response = $this->successResponse([ 
"message' => 'Nenhum registro encontrado’ 
], 404); 


if (!empty($resultWithDQL) && !empty($resultWithoutDQL)) { 
$response = $this->successResponse([ 
"result with dql' => $resultWithDQL, 
'result without dql' => $resultWithoutDQL 
1); 
} 
} catch (\Exception $e) { 
$response = $this->errorResponse( 


$e, 


'Erro ao listar o usuário com o id ' . $id, 
400 


)3 


return $response; 


} 


Vocé deve estar se perguntando: eu ja vi esse codigo em algum 
lugar? Sim, você viu! Esse código é igual ao do Handler 
TiposUsuarioListarUmHandler , mudando apenas o serviço que será 
chamado do contêiner de injeção de dependência para que 
possamos utilizar adequadamente. 


O código $service = $this->container->get (UsuariosService::class) 
demonstra exatamente o que foi descrito anteriormente. Essa é a 
única diferença deste código com relação ao código do Handler 
TiposUsuarioListarUmHandler ; OS demais códigos presentes no método 
não foram alterados e por isso não serão explicados novamente. 


Nosso próximo passo será criarmos a Factory do Handler 
UsuariosListarUmHandler para que possamos obter sua instância por 
meio do nosso contêiner de injeção de dependência. 


Criando a Factory UsuariosListarUmHandlerFactory 


Como já dito anteriormente, o único objetivo da Factory é retornar a 
instância de uma classe, e nesse caso faremos com o Handler 


UsuariosListarUmHandler . 


Crie a classe UsuariosListarUmHandlerFactory dentro do diretório 
src/App/src/Handler/Factory Conforme mostra a imagem a seguir: 
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O UsuariosListarHandlerFactory.php 


Figura 14.4: Criando a Factory UsuariosListarUmHandlerFactory 


Após a criação da Factory, seu código completo pode ser visto a 
seguir: 


<?php 
declare(strict_types=1) ; 


namespace App\Handler\Factory; 


use App\Handler\Usuarios\UsuariosListarUmHandler; 
use Psr\Container\ContainerInterface; 


pr 

* Class UsuariosListarUmHandlerFactory 
* @package App\Handler\Factory 
*/ 

class UsuariosListarUmHandlerFactory 


{ 


per 
* @param ContainerInterface fcontainer 
* (return UsuariosListarUmHandler 
e] 
public function _ invoke(ContainerInterface $container): 
UsuariosListarUmHandler 


{ 


return new UsuariosListarUmHandler($container); 


} 


Nenhuma novidade, não é mesmo? É bem parecida como qualquer 
outra Factory que criamos até o momento. Nesse caso, ela retorna 
uma instância do Handler usuariosListarUmHandler . 


O próximo passo é registrarmos esse Handler no arquivo de 
configuração configProvider e é isso que faremos em nossa próxima 
seção. 


Registrando o Handler UsuariosListarUmHandler 


Para registrarmos, abra o arquivo src/App/src/ConfigProvider.php € 
localize o método getDependencies() . Logo abaixo do registro 
Handler\Usuarios\UsuariosListarHandler::class QUe fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler \Usuarios\UsuariosListarUmHandler::class => 
Handler\Factory\UsuariosListarUmHandlerFactory::class, 


Pronto, mais um Handler registrado. Na próxima seção vamos criar 
o Handler responsável por criar um registro de usuário. 


14.3 Criando o Handler UsuariosCriarHandler 


Vamos criar o Handler que será responsável por criar um registro de 
usuário quando uma requisição post do HTTP for efetuada para a 
rota responsável. 


Crie a classe UsuariosCriarHandler dentro do diretório 
src/App/src/Handler/Usuarios , Conforme mostra a imagem a seguir: 
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Figura 14.5: Criando o Handler UsuariosCriarHandler 


Após a criação do Handler, vamos ver como é seu código completo 
a seguir: 


<?php 
declare(strict types=1); 


namespace App\Handler\Usuarios; 


use App\Handler\HandlerAbstract; 

use App\Service\UsuariosService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Laminas\Json\Json; 


per 
* Class UsuariosCriarHandler 
* @package App\Handler\Usuarios 
*/ 
class UsuariosCriarHandler extends HandlerAbstract implements 
RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
A 
public function handle(ServerRequestInterface $request): 
ResponseInterface 
{ 
try { 
$data = Json: :decode($request ->getBody()->getContents(), 
JSON OBJECT AS ARRAY); 


$service = $this->container->get(UsuariosService::class); 
$user = $service->insert ($data) ; 


$response = $this->successResponse($user, 201); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
"Erro ao criar um novo usuário', 
400 


)3 


return $response; 


Esse código também é bem semelhante ao do Handler 
TiposUsuarioCriarHandler . Note que a diferença é o código $service = 
$this->container->get (UsuariosService::class) , responsável por obter o 
serviço de usuário por meio do contêiner de injeção de 
dependência, e armazenar na variável $service. 


Isso é feito para que posteriormente possamos chamar o método 
insert($data) , que passa como parámetro O array de dados obtidos 
através da requisição. 


Nosso próximo passo é criar a Factory do Handler 


UsuariosCriarHandler . 
Criando a Factory UsuariosCriarHandlerFactory 


Essa Factory será responsável por retornar a instáncia da classe 
UsuariosCriarHandler . Crie a classe UsuariosCriarHandlerFactory dentro 
do diretório src/App/src/Handler/Factory/Usuarios conforme mostra a 
imagem a seguir: 
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Figura 14.6: Criando a Factory UsuariosCriarHandlerFactory 


A seguir, vamos ver como é o código completo dessa Factory: 


<?php 
declare(strict_types=1) ; 
namespace App\Handler\Factory; 


use App\Handler\Usuarios\UsuariosCriarHandler ; 


use Psr\Container\ContainerInterface; 


per 

* Class UsuariosCriarHandlerFactory 
* @package App\Handler\Factory 

e] 

class UsuariosCriarHandlerFactory 


{ 


Js 
* @param ContainerInterface $container 
* (return UsuariosCriarHandler 
dd 
public function _ invoke(ContainerInterface $container): 
UsuariosCriarHandler 


{ 


return new UsuariosCriarHandler($container) ; 


} 


O código não possui nenhum segredo, essa Factory retorna a 
instância da classe UsuariosCriarHandler e nada mais. 


Na próxima seção vamos realizar o registro desse Handler para que 
possamos utilizá-lo futuramente quando criarmos e testarmos as 
rotas da aplicação. 


Registrando o Handler UsuariosCriarHandler 


Para registrarmos, abra o arquivo src/App/src/ConfigProvider.php € 
localize o método getDependencies() . Logo abaixo do registro 
Handler\Usuarios\UsuariosListarUmHandler::class QUE fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler \Usuarios\UsuariosCriarHandler::class => 
Handler\Factory\UsuariosCriarHandlerFactory::class, 


Pronto, mais um Handler registrado e pronto para ser utilizado. Na 
próxima seção vamos criar o Handler responsável por realizar a 
alteração dos dados de um registro de usuário. 


14.4 Criando o Handler UsuariosAlterarHandler 


Esse Handler sera responsavel por realizar a alteragao dos dados 
de um determinado usuario. Primeiramente, crie a classe 
UsuariosAlterarHandler dentro do diretório 
src/App/src/Handler/Usuarios , Conforme mostra a imagem a seguir: 
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Figura 14.7: Criando o Handler UsuariosAlterarHandler 


Após a criação da classe, vamos ver como será seu código 
completo a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Usuarios; 


use App\Handler\HandlerAbstract; 

use App\Service\UsuariosService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Laminas\Json\J son; 


per 
* Class UsuariosAlterarHandler 
* @package App\Handler\Usuario 
*/ 
class UsuariosAlterarHandler extends HandlerAbstract implements 
RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
*/ 
public function handle(ServerRequestInterface $request): 
ResponseInterface 
{ 
try { 
$data = Json::decode($request->getBody()->getContents(), 
JSON OBJECT AS ARRAY); 
$data[ 'id'] = (int)$frequest->getAttribute('id'); 


$service = $this->container->get(UsuariosService::class); 
$user = $service->update($data); 


$response = $this->successResponse($user); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 


$e, 
'Erro ao alterar os dados do usuário!', 
400 


); 


return $response; 


} 


Como você pode ver, esse código também é bem semelhante ao do 
Handler TiposUsuarioAlterarHandler e temos apenas algumas 
diferenças. 


A primeira é o código $service = $this->container- 

>get (UsuariosService::class) , responsável por armazenar na variável 
$service O serviço de usuário obtido do contêiner de injeção de 
dependência. 


Em seguida, temos o código $user = $service->update($data) , 
responsável por realizar a alteração dos dados e armazenar o 
resultado da alteração na variável $user. 


Isso é feito para que possamos utilizá-la posteriormente no retorno 
do método, para que os dados possam ser enviados como resposta 
da requisição. 


O próximo passo é criarmos a Factory do Handler 


UsuariosAlterarHandler . 
Criando a Factory UsuariosAlterarHandlerFactory 


O objetivo dessa Factory é retornar a instância da classe 
UsuariosAlterarHandler para que a aplicação possa realizar a 
utilização do Handler corretamente. 


Crie a classe UsuariosAlterarHandlerFactory dentro do diretório 
src/App/src/Handler/Factory , conforme mostra a imagem a seguir: 
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Figura 14.8: Criando a Factory UsuariosAlterarHandlerFactory 


Após a criação da Factory, vamos ver seu código a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory; 


use App\Handler\Usuarios\UsuariosAlterarHandler; 


use Psr\Container\ContainerInterface; 


per 

* Class UsuariosAlterarHandlerFactory 
* (package App\Handler\Factory 

e] 

class UsuariosAlterarHandlerFactory 


{ 


Js 
* @param ContainerInterface $container 
* (return UsuariosAlterarHandler 
é 
public function _ invoke(ContainerInterface $container): 
UsuariosAlterarHandler 


{ 


return new UsuariosAlterarHandler($container); 


} 


Como dito anteriormente essa Factory possui a responsabilidade de 
retornar a instância da classe usuariosAlterarHandler , apenas isso e 
nada mais. 


O próximo passo é registrar o Handler para que nossa aplicação 
possa utilizá-lo corretamente. 


Registrando o Handler UsuariosAlterarHandler 


Para registrarmos, abra o arquivo src/App/src/ConfigProvider.php € 
localize o método getDependencies() . Logo abaixo do registro 
Handler\Usuarios\UsuariosCriarHandler::class que fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler\Usuarios\UsuariosAlterarHandler::class => 
Handler\Factory\UsuariosAlterarHandlerFactory::class, 


Após o registro desse Handler, podemos seguir em frente rumo ao 
ultimo Handler de usuário, que será responsável por realizar a 
exclusão de um determinado registro de usuário. 


14.5 Criando o Handler UsuariosD eletarHandler 


Esse Handler possui a responsabilidade de excluir um determinado 
registro de usuario do banco de dados através do id do usuario que 
devera ser informado no parametro da URL. 


Crie a classe UsuariosDeletarHandler dentro do diretório 
src/App/src/Handler/Usuarios , Conforme mostra a imagem a seguir: 
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Figura 14.9: Criando o Handler UsuariosDeletarHandler 


Após a criação da classe, vamos ver como é seu código completo: 


<?php 


declare(strict types=1); 


namespace App\Handler\Usuarios; 


use App\Handler\HandlerAbstract; 

use App\Service\UsuariosService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 


per 


* Class UsuariosDeletarHandler 
* @package App\Handler\Usuarios 


*/ 


class UsuariosDeletarHandler extends HandlerAbstract implements 
RequestHandlerInterface 


{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
public function handle(ServerRequestInterface $request): 
ResponseInterface 


{ 


$id = (int)frequest->getAttribute('id'); 


try { 
$service = $this->container->get(UsuariosService 
$service->delete($id) ; 


$response = $this->successResponse([ 
"message' => ‘Usuario deletado com sucesso!' 
1); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
'Erro ao deletar o usuário com o id ' . $id, 
400 


)3 


return $response; 


::class); 


} 


Novamente, o código é bem semelhante ao do Handler 
TiposUsuarioDeletarHandler € há apenas pequenas diferencas. 


A primeira é o código $service = $this->container- 
>get(UsuariosService::class) , que armazena na variável gservice O 
serviço de usuário obtido por meio do contêiner de injeção de 
dependência. 


A segunda diferença éo código $userDeleted = $service->delete($id) 
que é responsável por deletar o usuário e armazenar na variável 
$userDeleted O resultado da exclusão, que no caso é o usuário que 
foi excluído. O resultado é armazenado porque posteriormente 
vamos enviar esses dados como resposta no retorno do método, 
como você pode ver no código de retorno do método. 


Por fim, nosso próximo passo é criar a Factory desse Handler e é 
isso que faremos na próxima seção. 


Criando a Factory UsuarioDeletarHandlerFactory 


Agora pergunto: qual é o objetivo dessa Factory? Se você está 
pensando que é retornar a instância da classe 
UsuariosDeletarHandler , você acertou. 


Crie a classe UsuariosDeletarHandlerFactory dentro do diretório 
src/App/src/Handler/Factory , Conforme mostra a imagem a seguir: 
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Figura 14.10: Criando a Factory UsuariosDeletarHandlerFactory 


Com a criacáo da Factory, vamos ver seu código completo a seguir: 


<?php 


declare(strict types=1); 


namespace App\Handler\Factory; 


use App\Handler\Usuarios\UsuariosDeletarHandler; 
use Psr\Container\ContainerInterface; 


per 

* Class UsuariosDeletarHandlerFactory 
* @package App\Handler\Factory 

2 

class UsuariosDeletarHandlerFactory 


{ 
per 
* @param ContainerInterface fcontainer 
* (return UsuariosDeletarHandler 
ay 
public function _ invoke(ContainerInterface $container): 
UsuariosDeletarHandler 


{ 


return new UsuariosDeletarHandler($container); 


} 


O código dessa Factory é como os demais, não possui segredo 
nenhum. Ela possui apenas uma responsabilidade: criar a instância 
da classe UsuariosDeletarHandler e retorná-la para que a aplicação 
possa utilizá-la. 


Por último, falta registramos esse Handler para que possamos 
utilizá-lo corretamente quando formos definir as rotas da aplicação. 


Registrando o Handler UsuariosDeletarHandler 


Por fim, vamos registrar o Handler usuariosDeletarHandler , € COMO 
você já está bem acostumado, é bem simples fazer esse processo. 
Abra o arquivo src/App/src/ConfigProvider.php € localize o método 
getDependencies() . Logo abaixo do registro 
Handler\Usuarios\UsuariosAlterarHandler::class que fizemos 
anteriormente, coloque o código de registro a seguir: 


Handler\Usuarios\UsuariosDeletarHandler::class => 
Handler\Factory\UsuariosDeletarHandlerFactory::class, 


Mais um Handler esta devidamente registrado e pronto para ser 
utilizado pela nossa aplicação, e com isso chegamos ao final de 
mais um capítulo. 


Conclusão 


Vimos neste capítulo como criar o conjunto de Handlers de usuários, 
que serão responsáveis por listar, alterar, deletar e criar usuários. 
Não vimos nada de novo nesse processo, e, como você pôde ver, é 
um processo bem semelhante ao que fizemos no capítulo 13 com os 
Handlers de tipos de usuário. 


No próximo capítulo, faremos a criação do conjunto de Handlers que 
serão responsáveis pelos registros de mensagens dos usuários, 
como: listar, criar, alterar e deletar. Então, siga em frente e vamos 
nessa. 


CAPITULO 15 
Criando e registrando Handlers de Mensagens 


Neste capítulo, faremos a criação da sequência de Handlers que 
serão responsáveis pela troca de mensagens entre os usuários. 
Essa troca de mensagens não será em real-time (tempo real), mas 
sim inserida no banco de dados para que o usuário possa recuperar 
a mensagem e respondê-la. 


Assim como os demais Handlers que criamos nos capítulos 
anteriores, esses também não serão tão diferentes, pois a estrutura 
será basicamente a mesma, portanto, vamos nos debruçar apenas 
sobre as novidades. 


15.1 Criando o Handler MensagensListarHandler 


Vamos criar o Handler que será responsável por listar as 
mensagens cadastradas no banco de dados. Para isso, crie o 
diretório Mensagens dentro de src/App/src/Handler e, em seguida, crie 
a classe MensagensListarHandler dentro do diretório Mensagens , 
conforme mostra a imagem a seguir: 
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Figura 15.1: Criando o Handler MensagensListarHandler 
Vamos ver como é o código completo desse Handler a seguir: 
<?php 
declare(strict types=1); 
namespace AppiHandler Mensagens ; 
use App\Handler\HandlerAbstract; 


use App\Service\MensagensService; 
use Psr\Http\Message\ResponseInterface; 


use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 


per 

* Class MensagensListarHandler 

* @package App\Handler\Mensagens 

*/ 

class MensagensListarHandler extends HandlerAbstract implements 
RequestHandlerInterface 


{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
a 
public function handle(ServerRequestInterface $request): 
ResponseInterface 
{ 
try { 
$service = $this->container->get(MensagensService: :class); 
$resultWithDQL = $service->getAl1l(); 
$resultWithoutDQL = $service->getAl1WithDQL(); 
$response = $this->successResponse([ 
'result with dql' => $resultWithDQL, 
'result without dql' => $resultWithoutDQL 
1); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
"Erro ao listar todas as mensagens!', 
400 
)3 
} 
return $response; 
} 
} 


Como você pode ver no código do Handler, é exatamente a mesma 
estrutura de outros Handlers de listagem de registros presente nos 


capítulos anteriores. Inclusive, é exatamente a mesma quantidade 
de linhas. 


A única diferença presente éo código $service = $this->container- 
>get(MensagensService::class) , que é responsável por armazenar na 
variável $service O nosso serviço de mensagens que criamos no 
capítulo 12. 


O restante do código é bem simples e não foi alterado e por esse 
motivo não será explicado pois você já sabe exatamente o que ele 
faz, certo? Certo! 


Criando a Factory MensagensListarHandlerFactory 


O objetivo dessa Factory será retornar uma instância da classe 
MensagensListarHandler . Para isso, crie o diretório Mensagens dentro do 
diretório src/App/src/Handler/Factory €, em seguida, crie a classe 
MensagensListarHandlerFactory dentro do diretório 
src/App/src/Handler/Factory , conforme mostra a imagem a seguir: 
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Figura 15.2: Criando a Factory MensagensListarHandlerFactory 
A seguir vamos ver como é o código completo dessa Factory: 
<?php 
declare(strict types=1); 
namespace App\Handler\Factory; 


use App\Handler\Mensagens\MensagensListarHandler; 
use Psr\Container\ContainerInterface; 


fer 
* Class MensagensListarHandlerFactory 
* @package App\Handler\Factory 
es 


class MensagensListarHandlerFactory 


per 
* @param ContainerInterface fcontainer 
* (return MensagensListarHandler 
*7 
public function __invoke(ContainerInterface $container): 
MensagensListarHandler 


{ 


return new MensagensListarHandler($container); 


} 


Como dito anteriormente, essa Factory possui o objetivo de retornar 
apenas a instância da classe MensagensListarHandler . E simples 
assim. 


Nosso próximo passo é registrar o Handler para que a nossa 
aplicação saiba de sua existência para ser utilizado quando 
definirmos as rotas. 


Registrando o Handler MensagensListarHandler 


Como você já sabe, para registrarmos basta abrir o arquivo 

src/App/src/ConfigProvider.php € localizar o método getDependencies() . 
Logo abaixo do registro Handler\Usuarios\UsuariosDeletarHandler: :class 
que fizemos no capítulo anterior, digite o código de registro a seguir: 


HandleriMensagensiMensagensListarHandler::class => 
Handler\Factory\MensagensListarHandlerFactory::class, 


Na próxima seção vamos criar o Handler responsável por listar 
apenas uma mensagem através do id informado no parâmetro da 
URL. 


15.2 Criando o Handler 
MensagensListarUmaHandler 


Esse Handler sera responsável por listar apenas uma mensagem 
através do id da mensagem que deverá ser informado na URL. 


Para isso, crie a classe MensagensListarUmaHandler dentro do diretório 
src/App/src/Handler/Mensagens , conforme mostra a imagem a seguir: 
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Figura 15.3: Criando o Handler MensagensListarUmaHandler 


Após a criacáo do Handler, vamos ver como será seu código 
completo a seguir: 


<?php 


declare(strict_types=1) ; 


namespace App\Handler\Mensagens ; 


use App\Handler\HandlerAbstract; 

use App\Service\MensagensService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 


per 
* Class MensagensListarUmaHandler 
* @package App\Handler\Mensagens 
*/ 
class MensagensListarUmaHandler extends HandlerAbstract implements 
RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
EJ 
public function handle(ServerRequestInterface $request): 
ResponseInterface 


{ 
$id = (int)frequest->getAttribute('id'); 


try { 
$service = $this->container->get(MensagensService: :class); 
$resultWithDQL = $service->getOne($id) ; 
$resultWithoutDQL = $service->getOneWithDQL ($id) ; 


$response = $this->successResponse( [ 

‘error’ => true, 

"message' => 'Nenhum registro encontrado’ 
], 404); 


if (!empty($resultWithDQL) && !empty($resultWithoutDQL)) { 
$response = $this->successResponse([ 
"result_with_dgql' => $resultWithDQL, 
'result without dql' => $resultWithoutDQL 
1); 


} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
'Erro ao listar a mensagem com o id ' . $id, 
400 


); 


return $response; 


} 


Como você pode ver, o código é exatamente o mesmo do Handler 
UsuariosListarUmHandler , a única diferença é o código $service = 
$this->container->get(MensagensService::class) , que é responsável por 
armazenar na variável $service O serviço de mensagens para que 
posteriormente possa ser utilizado. 


O código é exatamente o mesmo, inclusive a quantidade de linhas 
do código anterior é igual ao do Handler usuariosListarUmHandler . 


Sem nenhum segredo, nosso próximo passo é criarmos a Factory 
desse Handler. 


Criando a Factory MensagensListarUmaHandlerFactory 


O objetivo dessa Factory é retornar uma instância da classe 
MensagensListarUmaHandler € nada mais. 


Para isso, crie a classe MensagensListarUmaHandlerFactory dentro do 
diretório src/App/src/Handler/Factory , conforme mostra a imagem a 
seguir: 
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Figura 15.4: Criando a Factory MensagensListarUmaHandlerFactory 


Após a criacáo da Factory, vamos ver como é seu código completo 
a seguir: 


<?php 
declare(strict_types=1) ; 
namespace App\Handler\Factory; 


use App\Handler\Mensagens\MensagensListarUmaHandler; 
use Psr\Container\ContainerInterface; 


per 

* Class MensagensListarUmaHandlerFactory 
* @package App\Handler\Factory 

id 


class MensagensListarUmaHandlerFactory 


{ 
[+ 
* (param ContainerInterface $container 
* (return MensagensListarUmaHandler 
*/ 
public function _ invoke(ContainerInterface $container): 
Mensagens ListarUmaHandler 


{ 


return new MensagensListarUmaHandler($container) ; 


} 


Como você pode ver no código, essa Factory não possui nada 
demais, não é mesmo? Seu objetivo é apenas retornar a instância 
da classe mensagensListarUmaHandler . 


Nosso próximo passo é registrarmos nosso Handler no arquivo de 
configuração. 


Registrando o Handler MensagensListarUmaHandler 


Para registrarmos, basta abrir o arquivo 
src/App/src/ConfigProvider.php € localizar o método getDependencies() . 
Logo abaixo do registro 

Handler \Mensagens\MensagensListarHandler::class QUE fizemos 
anteriormente, digite o código de registro a seguir: 


Handler \Mensagens\MensagensListarUmaHandler::class => 
Handler\Factory\MensagensListarUmaHandlerFactory::class, 


Na próxima seção vamos criar o Handler responsável por criar um 
registro de mensagem. 


15.3 Criando o Handler MensagensCriarHandler 


Este Handler sera responsavel por inserir as mensagens no banco 
de dados, e sera bem semelhante aos Handler 


TiposUsuarioCriarHandler € UsuariosCriarHandler . 


Primeiramente, crie a classe MensagensCriarHandler dentro do diretório 
src/App/src/Handler/Mensagens , conforme mostra a imagem a seguir: 
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Figura 15.5: Criando o Handler MensagensCriarHandler 


Após a criação da classe, vamos ver como é o código completo dela 
a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Mensagens ; 


use App\Handler\HandlerAbstract; 

use App\Service\MensagensService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Laminas\Json\Json; 


per 
* Class MensagensCriarHandler 
* @package App\Handler\Mensagens 
*/ 
class MensagensCriarHandler extends HandlerAbstract implements 
RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
*/ 
public function handle(ServerRequestInterface $request): 
ResponseInterface 


{ 
try { 


$data = Json: :decode($request ->getBody()->getContents(), 


JSON_OBJECT_AS_ARRAY); 


$service = $this->container->get(MensagensService: 
$message = $service->insert($data); 


$response = $this->successResponse($message, 201); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
'Erro ao criar um novo registro de mensagem!', 
400 


); 


:class); 


return $response; 


} 


O código também é bem simples e não possui segredo nenhum. Ha 
apenas três diferenças sutis. A primeira é o código $service = $this- 
>container->get (MensagensService::class) , que armazena na variável 
$service O Servico de mensagens obtido através do contêiner de 
injeção de dependências. 


A segunda está no código $message = $service->insert($data) , QUe 
armazena na variável $message O resultado da inserção da 
mensagem no banco de dados, retornando a mensagem inserida 
propriamente dita. 


A terceira diferença está no retorno do método, pois nele passamos 
a variável $message que contém o resultado da inserção para ser 
enviado para o cliente. 


Nosso próximo passo é criarmos a Factory desse nosso Handler. 
Criando a Factory MensagensCriarHandlerFactory 


O objetivo dessa Factory será retornar a instância da classe 
MensagensCriarHandler , para isso, crie a classe 
MensagensCriarHandlerFactory dentro do diretório 
src/App/src/Handler/Factory Conforme mostra a imagem a seguir: 
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Figura 15.6: Criando a Factory MensagensCriarHandlerFactory 


Após a criação da Factory, vamos ver como é o código completo 
dela a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory; 


use App\Handler\Mensagens\MensagensCriarHandler; 
use Psr\Container\ContainerInterface; 


per 
* Class MensagensCriarHandlerFactory 
* @package App\Handler\Factory 
e 


class MensagensCriarHandlerFactory 


{ 
[+ 
* @param ContainerInterface $container 
* @return MensagensCriarHandler 
*/ 
public function _ invoke(ContainerInterface $container): 
MensagensCriarHandler 


{ 


return new MensagensCriarHandler($container) ; 


} 


Como você pode notar, o código da Factory não possui nenhum 
segredo e retorna a instância da classe MensagensCriarHandler . 


O próximo passo é registrarmos o Handler no arquivo de 
configuracáo. 


Registrando o Handler MensagensCriarHandler 


Para registrarmos basta abrir o arquivo src/App/src/ConfigProvider. php 
e localizar o método getDependencies() . Logo abaixo do registro 
Handler\Mensagens\MensagensListarUmaHandler::class QUE fizemos 
anteriormente, digite o código de registro a seguir: 


Handler \Mensagens\MensagensCriarHandler::class => 
Handler\Factory\MensagensCriarHandlerFactory::class, 


Simples assim! Na próxima seção vamos criar o Handler 
responsável por realizar a alteração dos dados de um determinado 
registro de mensagem. 


15.4 Criando o Handler MensagensAlterarHandler 


O objetivo desse Handler será realizar a alteração dos dados de um 
determinado registro de mensagem através do id que deverá ser 


informado como parametro da URL da rota. 


Crie a classe MensagensAlterarHandler dentro do diretório 
src/App/src/Handler/Mensagens conforme a imagem a seguir: 
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Figura 15.7: Criando o Handler MensagensAlterarHandler 


Após a criação da classe, vamos ver como é o código completo dela 
a seguir: 


<?php 


declare(strict types=1); 


namespace App\Handler\Mensagens ; 


use App\Handler\HandlerAbstract; 

use App\Service\MensagensService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 
use Laminas\Json\J son; 


per 
* Class MensagensAlterarHandler 
* @package App\Handler\Mensagens 
*/ 
class MensagensAlterarHandler extends HandlerAbstract implements 
RequestHandlerInterface 
{ 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
EJ 
public function handle(ServerRequestInterface $request): 
ResponseInterface 


{ 
try { 
$data = Json: :decode($request ->getBody()->getContents(), 
JSON OBJECT AS ARRAY); 
$data[ 'id'] = (int)frequest->getAttribute('id'); 


$service 


$this->container->get(MensagensService: :class); 
$message = $service->update($data) ; 


$response = $this->successResponse($message) ; 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
"Erro ao alterar os dados da mensagem!', 
400 


J 


return $response; 


} 


O código também é bem semelhante com o que já vimos nos 
capítulos anteriores. Esse método possui três diferenças sutis e a 
primeira delas é o código $service = $this->container- 
>get(MensagensService::class) , que armazena na variável gservice O 
serviço de mensagens. 


A segunda éo código $message = $service->update($data) , QUE 
armazena na variável $message O resultado da alteração dos dados. 


E a terceira diferença está no retorno do método, no qual passamos 
para a chave data o resultado contido na variável $message , para ser 
enviado como resposta para o cliente. 


São apenas essas diferenças, o restante do código permanece o 
mesmo e sem alterações. O próximo passo é criar a Factory do 
nosso Handler. 


Criando a Factory MensagensAlterarHandlerFactory 


O objetivo dessa Factory será retornar uma instância da classe 
MensagensAlterarHandler , para isso, crie a classe 
MensagensAlterarHandlerFactory dentro do diretório 
src/App/src/Handler/Factory conforme mostra a imagem a seguir: 
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Figura 15.8: Criando a Factory MensagensAlterarHandlerFactory 


Após a criação da Factory, vamos ver o código completo dela a 
seguir: 


<?php 
declare(strict_types=1); 
namespace App\Handler\Factory; 


use App\Handler\Mensagens\MensagensAlterarHandler; 
use Psr\Container\ContainerInterface; 


per 

* Class MensagensAlterarHandlerFactory 
* @package App\Handler\Factory 

hs 


class MensagensAlterarHandlerFactory 


per 
* @param ContainerInterface fcontainer 
* (return MensagensAlterarHandler 
dd 
public function _ invoke(ContainerInterface $container): 
MensagensAlterarHandler 


{ 


return new MensagensAlterarHandler($container); 


} 


O código da Factory é simples e faz exatamente o que é esperado: 
retorna uma instância da classe MensagensAlterarHandler . 


O próximo passo é registrarmos o Handler como temos feito até o 
momento. 


Registrando o Handler MensagensAlterarHandler 


Para registrarmos, basta abrir o arquivo 
src/App/src/ConfigProvider.php € localizar o método getDependencies() . 
Logo abaixo do registro Handler\Mensagens\MensagensCriarHandler: :class 
que fizemos anteriormente, digite o código de registro a seguir: 


Handler\Mensagens\MensagensAlterarHandler::class => 
Handler\Factory\MensagensAlterarHandlerFactory::class, 


Na próxima seção vamos criar o Handler responsável por realizar a 
exclusão de um determinado registro de mensagem. 


15.5 Criando o Handler 
MensagensDeletarHandler 


O objetivo desse Handler é realizar a exclusao de um determinado 
registro de mensagem por meio do id informado como parametro 


da URL. 


Crie a classe MensagensDeletarHandler dentro do diretório 
src/App/src/Handler/Mensagens , Conforme mostra a imagem a seguir: 
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Figura 15.9: Criando o Handler MensagensDeletarHandler 


Após a criação do Handler, vamos ver seu código completo a seguir: 


<?php 


declare(strict types=1); 
namespace App\Handler\Mensagens ; 


use App\Handler\HandlerAbstract; 

use App\Service\MensagensService; 

use Psr\Http\Message\ResponselInterface; 

use Psr\Http\Message\ServerRequestInterface; 
use Psr\Http\Server\RequestHandlerInterface; 


per 

* Class MensagensDeletarHandler 
* @package App\Handler\Mensagens 
A 


class MensagensDeletarHandler extends HandlerAbstract implements 


RequestHandlerInterface 
É 
per 
* @param ServerRequestInterface $request 
* @return ResponseInterface 
sd 
public function handle(ServerRequestInterface $request): 
ResponseInterface 


{ 
$id = (int)frequest->getAttribute('id'); 


try { 
$service = $this->container->get(MensagensService 


$service->delete($id); 


$response = $this->successResponse([ 
'message' => 'Mensagem deletada com sucesso! ' 
1); 
} catch (\Exception $e) { 
$response = $this->errorResponse( 
$e, 
'Erro ao deletar a mensagem com o id ' . $id, 
400 


)3 


::class); 


return $response; 


} 


Como você já sabe bem, esse código também não é complexo e 
existem apenas duas diferenças se comparado com o código dos 
Handlers TiposUsuarioDeletarHandler € UsuariosDeletarHandler . 


A primeira diferença é o código ¢service = $this->container- 
>get(MensagensService::class) , que armazena na variável gservice O 
serviço de mensagens propriamente dito. 


A segunda diferença está no código $messageDeleted = $service- 
>delete($id) , que armazena na variável gmessageDeleted O resultado 
da exclusão do registro de mensagem, que é a própria mensagem 
que foi deletada. 


Com isso, podemos avançar para o próximo passo para criarmos a 
Factory desse Handler. 


Criando a Factory MensagensD eletarHandlerFactory 


O objetivo dessa Factory é retornar a instância da classe 
MensagensDeletarHandler , para isso, crie a classe 
MensagensDeletarHandlerFactory dentro do diretório 
src/App/src/Handler/Factory , conforme mostra a imagem a seguir: 
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Figura 15.10: Criando a Factory MensagensDeletarHandlerFactory 


Após a criação da Factory vamos ver como é o código completo 
dela a seguir: 


<?php 
declare(strict types=1); 
namespace App\Handler\Factory; 


use App\Handler\Mensagens\MensagensDeletarHandler; 
use Psr\Container\ContainerInterface; 


prs 


* Class MensagensDeletarHandlerFactory 


* @package App\Handler\Factory 
pe 
class MensagensDeletarHandlerFactory 


{ 


ft 
* @param ContainerInterface $container 
* (return MensagensDeletarHandler 
*/ 
public function __invoke(ContainerInterface $container): 
MensagensDeletarHandler 


{ 


return new MensagensDeletarHandler($container); 


} 


Não há nenhum segredo, a Factory retorna exatamente o esperado, 
que é uma instância da classe MensagensDeletarHandler . 


O próximo e último passo é registrar o Handler no arquivo de 
configuração. 


Registrando o Handler MensagensDeletarHandler 


Para registrarmos, basta abrir o arquivo 
src/App/src/ConfigProvider.php € localizar o método getDependencies() . 
Logo abaixo do registro 

Handler \Mensagens\MensagensAlterarHandler::class QUE fizemos 
anteriormente, digite o código de registro a seguir: 


Handler\Mensagens\MensagensDeletarHandler::class => 
Handler\Factory\MensagensDeletarHandlerFactory::class, 


Simples assim! Seu método getDependencies() deve ser parecido 
com o mostrado a seguir: 


public function getDependencies() : array 
return [ 
'invokables' => [ 
Handler\PingHandler::class => Handler\PingHandler::class, 


], 
"factories' => [ 
Handler\HomePageHandler::class => 
Handler\HomePageHandlerFactory::class, 
Handler\TestDoctrineConnectionHandler::class => 
Handler\Factory\TestDoctrineConnectionHandlerFactory::class, 


//Handlers de Tipos de Usuario 
Handler\TiposUsuario\TiposUsuarioListarHandler::class => 
Handler\Factory\TiposUsuarioListarHandlerFactory::class, 
Handler\TiposUsuario\TiposUsuarioListarUmHandler::class => 
Handler\Factory\TiposUsuarioListarUmHandlerFactory::class, 
Handler\TiposUsuario\TiposUsuarioCriarHandler::class => 
Handler\Factory\TiposUsuarioCriarHandlerFactory::class, 
Handler\TiposUsuario\TiposUsuarioAlterarHandler::class => 
Handler\Factory\TiposUsuarioAlterarHandlerFactory::class, 
Handler\TiposUsuario\TiposUsuarioDeletarHandler::class => 
Handler\Factory\TiposUsuarioDeletarHandlerFactory::class, 


//Handlers de Usuários 
Handler\Usuarios\UsuariosListarHandler::class => 
Handler\Factory\UsuariosListarHandlerFactory::class, 
Handler\Usuarios\UsuariosListarUmHandler::class => 
Handler\Factory\UsuariosListarUmHandlerFactory::class, 
Handler\Usuarios\UsuariosCriarHandler::class => 
Handler\Factory\UsuariosCriarHandlerFactory::class, 
Handler\Usuarios\UsuariosAlterarHandler::class => 
Handler\Factory\UsuariosAlterarHandlerFactory::class, 
Handler\Usuarios\UsuariosDeletarHandler::class => 
Handler\Factory\UsuariosDeletarHandlerFactory::class, 


//Handlers de Mensagens 
Handler\Mensagens\MensagensListarHandler::class => 
Handler\Factory\MensagensListarHandlerFactory::class, 
Handler\Mensagens\MensagensListarUmaHandler::class => 
Handler\Factory\MensagensListarUmaHandlerFactory::class, 
Handler\Mensagens\MensagensCriarHandler::class => 
Handler\Factory\MensagensCriarHandlerFactory::class, 
Handler\Mensagens\MensagensAlterarHandler::class => 
Handler\Factory\MensagensAlterarHandlerFactory::class, 
Handler\Mensagens\MensagensDeletarHandler::class => 


Handler\Factory\MensagensDeletarHandlerFactory::class, 


//Registrando Serviços 
Service\TiposUsuarioService::class => 
Service\Factory\TiposUsuarioServiceFactory::class, 
Service\UsuariosService::class => 
Service\Factory\UsuariosServiceFactory::class, 
Service\MensagensService::class => 
Service\Factory\MensagensServiceFactory::class 


J, 
]; 
} 


Com isso chegamos ao final do capítulo e também da série de 
criação de Handlers. 


Conclusão 


Vimos neste capítulo como criar os Handlers responsáveis pelo 
gerenciamento das mensagens. Vimos também que não há segredo 
algum se comparado com os demais Handlers dos capítulos 
anteriores, uma vez que a estrutura é a mesma e não tivemos que 
realizar a reescrita completa do código. 


Você poderá criar quantos Handlers for necessário. Experimente 
criar Handlers diferentes para alguma outra tarefa específica, como 
a de mensagens, por exemplo. Você pode criar um Handler capaz 
de obter todas as mensagens de um usuário específico, ou até 
mesmo um Handler capaz de deletar todas as mensagens de um 
determinado usuário. 


Nessa sequência de três capítulos, foram demonstrados como criar 
Handler e Factories e como registrar cada um deles no arquivo de 
configuração, que é uma etapa muito importante, já que, sem 
registrarmos os Handlers, nossa aplicação não saberia da existência 
deles e não poderia utilizá-los. 


No próximo capítulo, vamos criar as rotas da nossa aplicação para 
que possamos chamá-las em alguma aplicação cliente como 
Postman, ou o próprio navegador, dependendo do tipo da rota, 
então siga em frente! 


CAPITULO 16 
Definindo e testando as rotas da aplicação 


Agora que já temos todos os nossos Handlers definidos, chegou a 
hora de definirmos as rotas da nossa aplicação. É por meio dessas 
rotas que faremos a criação, listagem, alteração e exclusão dos 
registros. 


Você se lembra da rota que criamos no capítulo 7 que realiza o teste 
de conexão do Doctrine? E que a definimos no arquivo 
config/routes.php ? Caso não se recorde disso não tem problemas, 
pois veremos a seguir. Caso você se recorde, então já deve saber 
que é nele que definiremos as rotas da nossa aplicação. 


Cada Handler que criamos nos capítulos anteriores possuirá a sua 
própria rota, logo teremos um total de 15 (quinze) rotas. 


16.1 Definindo as rotas de tipos de usuário 


As primeiras rotas que vamos definir serão as de tipos de usuário 
que são pertencentes aos Handlers de tipos de usuário que criamos 
no capítulo 13. 


Para definirmos as rotas, vamos entender qual será o tipo de cada 
uma das rotas que vamos criar: 


Rota /api/tipos-de-usuario 


e Handler: TiposUsuarioListarHandler 

e Tipo da rota: GET 

e Motivo: esta rota é responsável por obter informações, logo o 
método HTTP responsável por isso é o aer, que será o tipo da 
rota. 


Rota /api/tipos-de-usuario/ 


e Handler: TiposUsuarioListarUmHandler 

e Tipo da rota: GET 

e Motivo: como esta rota também é responsável por obter 
informações, o tipo definido será cer . 


Rota /api/tipos-de-usuario 


e Handler: TiposUsuarioCriarHandler 

e Tipo da rota: post 

e Motivo: é responsável por realizar a gravação de informações 
no banco de dados, sendo assim, o método HTTP a ser 
utilizado é o Post , pois precisamos enviar um conjunto de 
dados no corpo da requisição. 


Rota /api/tipos-de-usuario/ 


e Handler: TiposUsuarioAlterarHandler 

e Tipo da rota: pur 

e Motivo: esta rota é responsável por realizar a alteração dos 
dados do registro, logo o método HTTP indicado é o put ou o 
PATCH . À diferença entre eles é que o pur é indicado quando 
desejamos alterar todos os dados de um determinado registro e 
O PATCH é quando desejamos alterar apenas alguns dados de 
um determinado registro. 


Rota /api/tipos-de-usuario/ 


e Handler: TiposUsuarioDeletarHandler 

e Tipo da rota: DELETE 

e Motivo: como o objetivo dessa rota é excluir um registro, o 
método HTTP indicado é O DELETE . 


Agora que temos as nossas rotas definidas, temos que as definir no 
código do nosso arquivo config/routes.php e é exatamente isso que 
faremos logo a seguir. 


Definindo a rota para listar os tipos de usuario 


Abra o arquivo config/routes.php €, logo abaixo da rota /api/test- 
doctrine-connection QUe criamos no capítulo 7, insira o código a 
seguir: 


$app->get ( 
'/api/tipos-de-usuario', 
App\Handler\TiposUsuario\TiposUsuarioListarHandler::class, 
'api.tipos-de-usuario.listar-todos' 


)3 


Agora vamos entender o que esse código está fazendo. O trecho 
$app->get Significa que estamos definindo a rota do tipo cer do 
HTTP. Esse tipo de método é utilizado quando desejamos obter 
informações. 


O método get recebe 3 parâmetros em ordem, são eles: 


e 1º - Path - é a rota propriamente dita, ou seja, a rota que sera 
chamada pela aplicação cliente para fazer a requisição. Em 
nosso caso, é a rota /api/tipos-de-usuario . 

e 2º - Middleware/Handler - é o Handler que criamos 
anteriormente e que foi registrado no arquivo de configuração 
ConfigProvider.php . Deve ser exatamente o mesmo nome que foi 
definido neste arquivo. Em nosso caso, é o Handler 
App\Handler\TiposUsuario\TiposUsuarioListarHandler::class , QUe é 
responsável por realizar a listagem de todos os tipos de 
usuários. 

e 3º - Name - é o nome que desejarmos dar para a rota. Esse 
parâmetro é opcional, mas em nosso código definimos o nome 
api.tipos-de-usuario.listar-todos , Mas você pode definir o nome 
que desejar, desde que o nome seja único para cada rota. 


Perceba como é simples definir uma rota no Mezzio. Esse pequeno 
trecho de código já funciona muito bem e mais adiante neste 
capítulo faremos os testes das rotas. 


Definindo a rota para listar apenas um tipo de usuario 


A próxima rota que vamos definir é que retornará apenas um tipo de 
usuário, com base no id que será informado como parâmetro da 
requisição. 


Com o arquivo config/routes.php aberto, digite ou insira o código a 
seguir: 


$app->get( 
"/api/tipos-de-usuario/{id}', 
App\Handler\TiposUsuario\TiposUsuarioListarUmHandler::class, 
'api.tipos-de-usuario.listar-um' 


da 


Perceba que essa rota também é do tipo cet igual a que definimos 
anteriormente. Veja o código /api/tipos-de-usuario/{id} que estamos 
definindo, essa rota é responsável por retornar apenas um tipo de 
usuário e isso será possível gracas ao parámetro id que está 
definido entre chaves {}. 


No Handler TiposUsuarioListarUmHandler , é esse parámetro que 
estamos recuperando e convertendo em número inteiro para ser 
utilizado. 


Os demais trechos do código sáo basicamente os mesmos, 
mudando apenas o Handler que está sendo chamado e também o 
nome da rota. 


Definindo a rota para criar um registro de tipo de usuário 


Agora vamos definir a rota que será responsável por realizar a 
criacáo/insercáo de registros de tipos de usuário. Veja a seguir 
como é o código de definicáo dessa rota: 


$app->post( 
'/api/tipos-de-usuario', 
AppYHandlerYTiposUsuariolYTiposUsuarioCriarHandler::class, 


'api.tipos-de-usuario.criar' 


)3 


A primeira diferença a ser notada no código anterior é o trecho ¢app- 
>post , que indica que estamos definindo uma rota do tipo post do 
HTTP. 


Esse tipo de rota é definido quando desejamos realizar inserção de 
dados e precisamos enviar um conjunto de dados no corpo da 
requisição. 


Perceba também que a estrutura do método $app->post é a mesma 
do método $app->get , OU Seja, possui 3 parámetros: path, Handler € 


Name . 


Sempre que você for definir uma rota, lembre-se de informar o 
Handler correspondente que foi criado e registrado no arquivo de 
configuração configProvider.php , isso é muito importante. 


Definindo a rota para alterar os dados de um registro de tipo de 
usuário 


Vamos definir agora como será o código de definição da rota 
responsável por realizar a alteração dos dados de um determinado 
registro de tipo de usuário por meio do id que será informado como 
parâmetro da URL. 


Veja a seguir como é o código de definição dessa rota: 


$app->put( 
"/api/tipos-de-usuario/{id}', 
App\Handler\TiposUsuario\TiposUsuarioAlterarHandler::class, 
'api.tipos-de-usuario.alterar' 


)5 


A primeira diferença a notar no código é o trecho gapp->put , que 
indica que estamos definindo uma rota do tipo put do HTTP. O 
método put é bem semelhante ao post . É indicado para realizar 
alteração de dados e, assim como o post , ele também permite 


enviar um conjunto de dados no corpo da requisição sem que o 
usuário veja os dados sendo enviados. 


Outra diferença é a presença do parâmetro id, que foi definido 
entre chaves {}. Esse parâmetro será recuperado dentro do 
Handler tiposUsuarioAlterarHandler que criamos lá no capítulo 13. 


As demais diferenças são no Handler e no nome da rota, como você 
já sabe. 


Definindo a rota para deletar um registro de tipo de usuário 


A última rota de tipo de usuário que vamos definir é a que será 
responsável por excluir um registro de tipo de usuário com base no 
id que será informado como parâmetro da URL. 


Vejamos a seguir como é o código dessa rota: 


$app->delete( 
"/api/tipos-de-usuario/{id}', 
App\Handler\TiposUsuario\TiposUsuarioDeletarHandler::class, 
'api.tipos-de-usuario.deletar' 


)3 


A diferença desse código é o trecho $app->delete , que informa que o 
tipo da rota é DELETE do HTTP. Esse método é indicado quando 
desejamos realizar a exclusão de registros do banco de dados. 


Perceba novamente a presença do parâmetro id definido entre 
chaves {}. Ele é recuperado e utilizado dentro do Handler 
TiposUsuarioDeletarHandler Que criamos e registramos no capítulo 13. 


Além disso, note que a estrutura do método delete também não foi 
alterada, se comparado com todos os demais métodos que 
utilizamos anteriormente neste capítulo. 


Vale lembrar que é muito importante atentar-se ao Handler que você 
criou e chamá-lo quando estiver definindo as suas rotas, nunca se 
esqueça disso. 


Agora que já definimos todas as rotas de tipos de usuários, nós 
realizaremos os testes para garantirmos que estão funcionando 
conforme o esperado. 


16.2 Testando as rotas de tipos de usuário 


Para realizar os testes, usaremos o Postman para fazer as 
requisições, mas você poderá utilizar outra aplicação capaz de fazer 
o mesmo. 


Testando a rota para criar um registro de tipo de usuário 


Com o Postman ou sua aplicação capaz de fazer requisições aberta, 
informe na URL o endereço http://projeto-mezzio.local/api/tipos-de- 


usuario. 


Altere o tipo de método HTTP para post e, no corpo da requisição, 
informe o código JSON a seguir: 


{ 
"tipo": "Visitante", 
"ativo": true 


} 


Você pode estar se perguntando: mas como sei que são esses 
dados que devo enviar? A resposta é simples: por meio da sua 
entidade TiposUsuario que melhoramos lá no capítulo 8. É 
importante mencionar que o nome do campo tem que ser 
exatamente o mesmo nome definido na propriedade da entidade, ou 
seja, tipo Vai funcionar, enquanto Tipo não. Atente-se bem a isso, 
certo? 


Se você definiu a rota, o método a ser utilizado na requisição e o 
conjunto de dados corretamente, ao submeter a requisição você 
deverá ter uma resposta semelhante à mostrada a seguir: 


POST * | http:/projeto-mezzio.local/apistipos-de-usuario 
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Body lers (6) Test U 
Pretty T JSON * 5 
1 | 
2 "data": ( 
3 "id": 1, 
+ "tipo": “Visitante”, 
5 “is ativo": true, 
6 “criado em”: { 
T "date": "2020-02-21 10:17: 40.688567", 
B "timezone type": 3, 
5 "timezone": “America/5ao Paulo” 
10 +. 
11 “alterado em": null, 
12 “deletado em": null 
13 } 
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Figura 16.1: Resposta da inserção do tipo de usuário 


Testando a rota para alterar os dados de um registro de tipo de 
usuário 


Agora altere a URL no seu cliente de requisição para http://projeto- 
mezzio.local/api/tipos-de-usuario/1 . Altere também o tipo da 
requisição para put e informe o JSON a seguir no corpo da 
requisição: 


{ 


"ativo": false, 
"alteradoEm" : "2018-07-24 15:06:02" 
} 


Neste caso, estamos inativando o registro através do campo ativo, 
que possui valor false , e estamos informando a data da alteração 
do registro. 


Se você definiu novamente tudo corretamente, você deverá ter uma 
saída semelhante à mostrada a seguir: 
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v http://projeto-mezzio.local/api/tipos-de-usuario/1 


form-data x-www-form-urlencoded ™® raw binary GraphQL 


“ativo”: false, 
“alteradoEm": "2020-02-21 10:38:42" 


(6) 


"data": { 

"id": FP 

“tipo": “Visitante”, 

“is ativo": false, 

“criado em": { 
"date": "2020-02-21 10:17:40.000000”, 
“timezone type": 3, 
"timezone": “America/Sao Paulo” 

+. 

“alterado em": 4 
"date": "2020-02-21 10:39:02.333248", 
“timezone type": 3, 
“timezone”: “America/Sao Paulo” 

k. 


“deletado em": null 


Figura 16.2: Resposta da alteração do tipo de usuário 


Testando a rota para listar todos os registros de tipos de 
usuário 


Vamos testar a rota que é responsável por realizar a listagem de 
todos os registros de tipos de usuário inseridos no banco de dados. 


Para isso, informe a rota http: //projeto-mezzio.local/api/tipos-de- 
usuario Que Criamos anteriormente e, em seguida, altere o tipo de 
requisição para cer e submeta a requisição. 


Se tudo ocorreu bem, você deverá ter uma saída semelhante à 
exibida na imagem a seguir: 


GET 


Body 


Cookies 


Pretty 
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ial 


* = httpi/projeto-mezzio.local/api/tipos-de-usuario 


Dana 
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Test Results 


Visualize JSON * 5 


“result with dgl": [ 


"id": 1, 

"tipo": “Visitante”, 

“is ativo": false, 

“criado em": { 
"date": "2620-62-21 10:17:46.000000", 
"timezone type": 3, 
"timezone": “America/Sao Paulo" 

+. 

“alterado em": 4 
"date": "2020-02-21 10:39:02,000000”, 
"timezone type": 3, 
"timezone": “America/5Sao Paulo" 

+. 


“deletado em": null 


“result without dql": [ 


"data": { 
{ 
} 
1, 
i 
] 


"id": 1, 
"tipo": "Visitante”, 
"ativo": false 


Figura 16.3: Resposta da listagem de todos os tipos de usuários 


Um ponto importante a ser considerado: perceba que a chave 
result_with_dql possui todos os campos da entidade, enquanto o 
campo result without dgl possui apenas alguns. Isso foi feito para 
mostrar a você a flexibilidade que você possui ao trabalhar com o 

Doctrine. 


Testando a rota para listar apenas um registro de tipo de 
usuário 


Agora vamos testar a nossa rota que retorna apenas um tipo de 
usuário com base no id que será informado na URL. Altere a URL 
em seu cliente de requisição para http://projeto- 
mezzio.local/api/tipos-de-usuario/1. O tipo de requisição deve ser o 
mesmo, no caso O GET. 


Em seguida, submeta a requisicáo e veja se o seu resultado é 
semelhante ao obtido na imagem a seguir: 


GET 
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l 
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https! projeto-mezzio.local/api/tipos-de-usuarios] 
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"data": 1 


“result with dql”: { 

"id": 1, 

"tipo": “Visitante”, 

“is ativo": false, 

“criado em": { 
"date": "2020-62-21 10:17:46. 606060", 
“timezone type": 3, 
"timezone": “America/5ao Paulo" 

Te 

“alterado em": { 
"date": "2020-62-21 10:39:62. 606000", 
“timezone type": 3, 
"timezone": "“America/Sao Paulo" 


Te 
“deletado em": null 
fe 
“result_without_dql": [ 
{ 
"id": 1, 
"tipo": “Visitante”, 
"ativo": false 
k 
] 


Figura 16.4: Resposta da listagem de apenas um registro de tipo de usuario 


Testando a Rota Para Deletar Um Registro de Tipo de Usuario 


Por fim, vamos testar a ultima rota de tipos de usuario. Ela é 
responsavel por deletar um registro de tipo de usuario do banco de 
dados. 


Para testa-la, informe a URL http: //projeto-mezzio.local/api/tipos-de- 
usuario/1 em seu cliente de requisição, altere o método da 
requisição para DELETE e, em seguida, submeta a requisição. 


Veja se o seu resultado obtido é semelhante ao mostrado na 
imagem a seguir: 


DELETE v nttp://projeto-mezzio.local/api/tipos-de-usuario/1 
(9) Body 
® none form-data x-www-form-urlencoded raw binary Graphc 
Body (6) 
Pretty = 
1 4 
2 "data": ( 
3 “message”: "O tipo de usuário foi deletado com sucesso!” 
4 } 
> &§ 


Figura 16.5: Resposta da exclusao de um registro de tipo de usuario 


Se o seu resultado for semelhante, parabéns, as rotas de tipos de 
usuario estao funcionando perfeitamente. 


Com isso, finalizamos a definição e testes das rotas de tipos de 
usuarios e estamos prontos para seguir em frente. 


16.3 Definindo as rotas de usuarios 


As próximas rotas que vamos definir serão as de usuários, que sao 
pertencentes aos Handlers de usuários que criamos no capítulo 14. 


Vamos entender qual será o tipo de cada uma das rotas que vamos 
criar: 


Rota /api/usuarios 


e Handler: UsuariosListarHandler 

e Tipo da rota: GET 

e Motivo: esta rota é responsável por obter informações, logo o 
método HTTP responsável por isso é o aer, que será o tipo da 
rota. 


Rota /api/usuarios/ 


e Handler: UsuariosListarUmHandler 

e Tipo da rota: GET 

e Motivo: como essa rota também é responsável por obter 
informações o tipo definido será GET. 


Rota /api/usuarios 


e Handler: UsuariosCriarHandler 

e Tipo da rota: post 

e Motivo: É responsável por realizar a gravação de informações 
no banco de dados, sendo assim, o método HTTP a ser 
utilizado é o Post , pois precisamos enviar um conjunto de 
dados no corpo da requisição. 


Rota /api/usuarios/ 


e Handler: UsuariosAlterarHandler 

e Tipo da rota: pur 

e Motivo: esta rota é responsável por realizar a alteração dos 
dados do registro, logo o método HTTP indicado é o put ou o 


PATCH . À diferença entre eles é que o pur é indicado quando 
desejamos alterar todos os dados de um determinado registro e 
O PATCH é quando desejamos alterar apenas alguns registros. 


Rota /api/usuarios/ 


e Handler: UsuariosDeletarHandler 

e Tipo da rota: DELETE 

e Motivo: como o objetivo dessa rota é excluir um registro, entáo 
o método HTTP indicado é O DELETE . 


Agora que temos as nossas rotas, temos que as definir no código do 
NOSSO arquivo config/routes.php . Antes, perceba que a tabela 
mostrada é exatamente a mesma da tabela de tipos de usuarios que 
criamos no começo do capitulo, não houve alterações na explicação 
porque nossa aplicação segue exatamente a mesma estrutura, 
mudamos apenas as rotas e os Handlers. 


Vamos definir as rotas dentro da nossa aplicação. 
Definindo a rota para listar os usuários 


Antes de seguirmos, vale informar que a estrutura dos códigos de 
definição das rotas também é a mesma que já foi explicada 
anteriormente, mudando apenas a rota, o Handler e o nome da rota. 
Veja a seguir o código de definição da desta rota: 


S$app->get( 
'/api/usuarios', 
App\Handler\Usuarios\UsuariosListarHandler::class, 
"api.usuarios.listar-todos' 


Já 


Definindo a rota para listar apenas um usuário 


A próxima rota que vamos definir é a que retornará apenas um 
usuário baseado no id que será informado como parâmetro da 
requisição. 


Digite ou insira o código a seguir em seu arquivo config/routes.php : 


tapp->get( 
'/api/usuarios/(id)', 
App\Handler\Usuarios\UsuariosListarUmHandler::class, 
"api.usuarios.listar-um' 


); 
Definindo a rota para criar um registro de usuário 


Agora vamos definir a rota que será responsável por realizar a 
criação/inserção de registros de usuários, veja o código a seguir: 


$app->post( 
'/api/usuarios', 
App\Handler\Usuarios\UsuariosCriarHandler::class, 
'api.usuarios.criar' 


3 


Definindo a rota para alterar os dados de um registro de 
usuário 


Vamos definir agora como será o código de definicáo da rota 
responsável por realizar a alteracáo dos dados de um determinado 
registro de usuario por meio do id, que será informado como 
parámetro da URL. 


$app->put ( 
"/api/usuarios/{id}', 
App\Handler\Usuarios\UsuariosAlterarHandler::class, 
'api.usuarios.alterar' 


)3 


Definindo a rota para deletar um registro de usuario 


A última rota de usuários que vamos definir é a que sera 
responsavel por excluir um registro de usuario com base no id que 
será informado como parâmetro da URL. 


Veja a seguir o código dessa rota: 


$app->delete( 
'/api/usuarios/(id)', 
App\Handler\Usuarios\UsuariosDeletarHandler::class, 
'api.usuarios.deletar' 


)5 


Pronto, finalizamos a definição das rotas de usuários e como você 
pôde ver não mudou muita coisa, inclusive a estrutura de definição 
das rotas é a mesma. Como foi descrito anteriormente, apenas 
mudamos as rotas, os Handlers e o nome das rotas. 


Agora podemos realizar os testes para verificarmos se tudo está 
funcionando corretamente. 


16.4 Testando as rotas de Usuários 


Como você já sabe, estou utilizando o Postman para realizar os 
testes, mas você poderá utilizar outra aplicação capaz de realizar as 
requisições. 


Testando a rota para criar um registro de tipo de usuário 


Antes de prosseguirmos, é importante lembrar que, como excluímos 
o registro de tipo de usuário com o nosso último teste, será 
necessário criá-lo novamente. Esse passo você deverá fazer por 
meio da requisição de criar tipo de usuário. Depois siga para o 
passo descrito a seguir. 


Com o seu cliente de requisições aberto, informe na URL o 
endereço http://projeto-mezzio.local/api/usuarios . 


Altere o tipo de método HTTP para post e, no corpo da requisição, 
informe o código JSON a seguir: 


{ 
"tipoUsuario": 2, 
"nomeCompleto" : "Nome Completo do Usuário", 
"cpf": "35525545595", 
"dataNascimento" : "19100-06-06", 
"email": "emaildousuario@dominio.com.br", 
"senha": "123456", 
"ativo": true 


} 


No conjunto de dados a ser enviado para a requisição, não ha 
segredo algum. O único ponto a ser levado em consideração e é 
extremamente importante é a chave tipousuario . Essa chave deve 
possuir o id do registro de tipo de usuário existente; caso o valor 
inexistente seja informado, um erro ocorrerá. Logo, atente-se a isso, 
pois você deverá informar um id de tipo de usuário existente em 
seu banco de dados. 


Com tudo preparado e pronto para ser enviado, submeta a 
requisição. 


Se o resultado obtido for semelhante ao mostrado na imagem a 
seguir, significa que está tudo certo e poderemos seguir em frente: 


POST - http'projeto-mezzio.localfapi'usuarios 
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18 "is ativo": true, 
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21 “timezone type": 3, 
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Figura 16.6: Resposta da insercáo de um registro de usuário 


Testando a rota para alterar os dados de um registro de usuário 


Agora altere a URL no seu cliente de requisição para http://projeto- 
mezzio.local/api/usuarios/1 , altere também o tipo da requisição para 
put e informe o JSON a seguir no corpo da requisição: 


{ 
"nomeCompleto" : "Nome Completo do Usuário de Teste”, 
"cpf": "45333586715", 
"dataNascimento": "2000-01-01", 
"email": "emaildousuario@dominio.com" , 
"senha": "123", 
"ativo": false, 
"alteradoEm" : "2018-07-25 11:00:15" 
} 


Nesse caso, estamos inativando o registro através do campo ativo 
igualmente fizemos com o registro de tipo de usuário que possui 
valor false e estamos informando a data da alteração do registro. 
Também estamos alterando todos os demais campos. Se você 
definiu tudo corretamente, então você deverá ter uma saída 
semelhante à mostrada a seguir: 


PUT 
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"data": { 
"id": 1, 


“tipo usuario”: { 
"initializer ”: {}. 
"cloner": Th, 
"_isInitialized ": false 
+. 
"nome completo": "Nome Completo do Usuário de Teste”, 
"cpt": "45333586715", 
“data nascimento": 1 
"date": "2008-61-01 00:00:00.000000”, 
“timezone type": 3, 
"timezone": “America/Sao Paulo" 
) 
"email": "emaildousuariogdominio.com”, 
"senha": "202cb962ac590750964b07152d234b70", 
“is ativo": false, 
"criado em": ( 
"date": "2620-62-21 12:21:49.000000”, 
“timezone type": 3, 
"timezone": “America/Sa0 Paulo” 


"alterado em": { 
"date": "2620-62-21 12:28:07.657174”, 
“timezone type": 3, 
"timezone": "America/Sao Paulo” 
Ji 
“deletado em”: null 


Figura 16.7: Resposta da alteração dos dados do usuário 


Testando a rota para listar todos os registros de usuarios 


Vamos testar a rota que é responsável por realizar a listagem de 
todos os registros de usuários inseridos no banco de dados. Para 
isso, informe a rota http://projeto-mezzio.local/api/usuarios , em 
seguida, altere o tipo de requisição para cet e submeta a 
requisição. 


Se tudo ocorreu bem, você deverá ter uma saída semelhante à 
mostrada na imagem a seguir: 
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"result_with_dgl": [ 


Raw Preview 
"data": { 
{ 
} 


"id": 1, 
“tipo usuario”: { 


Fe 


“nome completo": "Nome Completo do Usuario de Teste”, 
“cpf”: "453335896715", 
“data nascimento": { 

“date”: “2000-01-01 86:60:08. 080800", 


SON * 


“timezone type": 3, 


“timezone”: “America/Sao Paulo” 


Fe 


“email”: "emaildousuariogdominio. com", 
“senha”: "282cb0623c590755964b07152d234b70", 


"is ativo": false, 
"criado em": { 


“date”: "2020-82-21 12:21:49. 0680060", 


“timezone type” 


“timezone”: “America/Sao Paulo” 


Fe 
"alterado_em": { 


"date": "2020-02-21 12:28:07.000000", 


+ 


3, 


“timezone type”: 3, 


“timezone”: “Americaf5ao Paulo” 


Fe 


“deletado em": mull 


“result without dql": [ 


{ 


"id": 1, 


"nomeCompleto”: “Nome Completo do Usuário de Teste”, 


“ativo”: false, 


"cpf": "45333586715", 


"dataMascimento”: 


{ 


= 


— ânitializer “: Uh, 
_ cloner": dl, 
_ dsInitialized ": 


false 


Figura 16.8: Resposta da listagem de apenas um registro de usuario 
Testando a rota para listar apenas um registro de usuario 


Agora vamos testar a nossa rota que retorna apenas um usuario 
com base no id que sera informado na URL. Altere a URL em seu 
cliente de requisição para http://projeto-mezzio.local/api/usuarios/1 , 
o tipo de requisição deve ser o mesmo, no caso O GET. 


Em seguida, submeta a requisição e veja se o seu resultado é 
semelhante ao obtido na imagem a seguir: 


GET “ hitps//livro-zend-expressive.dev/apifusuarios/listar-um/1 








Key Value 
Content-Type application/json 
Body Cookies Headers (5) Test Results 
Pretty Raw Previews JSON w = 


1 

2 “result with dgl”: { 

3 "id": 1, 

4 “nome completo”: "Nome Completo do Usuario de Teste”, 


5 "cpf": "45333586715", 

Gr “data nascimento: { 

T “date”: "7000- aas 61 86:60:00. 000006", 
B “timezone type” F, 

gy "timezone" “Aner ica/Sao | Paulo” 

18 

11 “email”: “enaildousuar iogdominio. com”, 

12 “senha” ¿202cb962ac59075b964b07152d234b70" E 
13 “is ativo” AR Li 

14 — "criado . en” 

15 "date": "2818-07-25 19:44:62. 6066888”, 
16 e li 3, 

17 "timezone" "America/Sao_ Paulo” 

18 (He 

19 + alterado em: { 

20 "date" "2818- 67-25 11:32:26. 06060008" 
21 “timezone a! Es 

22 “timezone” “America/Sao_ Paulo” 

23 +. 

24 “deletado em": null, 

257 “tipo usuario: { 

26 "initializer": {}, 

27 =—_cloner_": 

2B F —isInitlalized _ =": false 

29 } 

36 +. 

31 ~ “result without dgl": [ 

32 + { 

33 "id": 1, 

34 “nomeCompLleto": “Nome Completo do Usuario de Teste”, 
as “ativo”: false, 

36 “cpf”: "45333586715", 

a7 “dataNascimento”: { 

38 “date”: "2006-01-01 00:60:00.000086”, 
39 “timezone type”: 3, 
46 } “timezone”: “Americas Sac Paulo” 
41 y 

42 “email”: "emaildousuariofdominio.com”, 
43 "tipollsuario”: 4 

44 + 

45 1 


Figura 16.9: Resposta da listagem de apenas um registro de usuario 
Testando a rota para deletar um registro de usuario 


Por fim, vamos testar a ultima rota de usuarios, responsavel por 
deletar um registro de usuario do banco de dados. 


Para testa-la, informe a URL http: //projeto-mezzio/api/usuarios/1 em 
seu cliente de requisição, altere o método da requisição para DELETE 
e, em seguida, submeta a requisição. Veja se o seu resultado obtido 
é semelhante ao mostrado na imagem a seguir: 


DELETE F http:orojeto-mezzioJocal/apifusuanass 1 
(9) Body 
Y none form-data anna form-urltencoded raw bi 
Body (6) 

Pretty OM F = 

1 H 

2 "data": { 

3 “message”: “Usuario deletado com sucesso!" 


Ln En 
ha 


Figura 16.10: Resposta da exclusáo de um registro de usuário 


Se o seu resultado for semelhante, entáo está tudo certo. Com isso, 
finalizamos a definicáo e testes das rotas de usuários e estamos 


prontos para seguir em frente. 


16.5 Definindo as rotas de Mensagens 


As próximas rotas que vamos definir serão as de mensagens que 
são pertencentes aos Handlers de mensagens que criamos no 
capítulo 15. 


Vamos entender qual será o tipo de cada uma das rotas que vamos 
criar. Você vai perceber novamente que nada mudará na descrição 
das rotas e nem nos tipos. 


Rota /api/mensagens 


e Handler: MensagensListarHandler 

e Tipo da rota: GET 

e Motivo: esta rota é responsável por obter informações, logo o 
método HTTP responsável por isso é o aer, que será o tipo da 
rota. 


Rota /api/mensagens/ 


e Handler: MensagensListarUmHandler 

e Tipo da rota: GET 

e Motivo: como esta rota também é responsável por obter 
informações, o tipo definido será cer . 


Rota /api/mensagens 


e Handler: MensagensCriarHandler 

e Tipo da rota: post 

e Motivo: é responsável por realizar a gravação de informações 
no banco de dados, sendo assim, o método HTTP a ser 


utilizado é o post , pois precisamos enviar um conjunto de 
dados no corpo da requisição. 


Rota /api/mensagens/ 


e Handler: MensagensAlterarHandler 

e Tipo da rota: put 

e Motivo: esta rota é responsável por realizar a alteração dos 
dados do registro, logo o método HTTP indicado é o put ou o 
PATCH . À diferença entre eles é que o put é indicado quando 
desejamos alterar todos os dados de um determinado registro e 
O PATCH é quando desejamos alterar apenas alguns registros. 


Rota /api/mensagens/ 


e Handler: MensagensDeletarHandler 

e Tipo da rota: DELETE 

e Motivo: como o objetivo dessa rota é excluir um registro, então 
o método HTTP indicado é O DELETE . 


Agora que temos as nossas rotas definidas, temos que as definir no 
código do nosso arquivo config/routes.php . 


Agora vamos definir as rotas dentro da nossa aplicação. 
Definindo a rota para listar as mensagens 


A estrutura é a mesma que já conhecemos. Veja a seguir o código 
de definição da desta rota: 


$app->get( 
'/api/mensagens', 
App \Handler\Mensagens\MensagensListarHandler::class, 
'api.mensagens.listar-todas' 


)5 


Definindo a rota para listar apenas uma mensagem 


A próxima rota que vamos definir é a que retornará apenas uma 
mensagem com base no id que será informado como parâmetro da 
requisição. 


Insira o código a seguir em seu arquivo config/routes.php : 


tapp->get( 
'/api/mensagens/(id)', 
App \Handler\Mensagens\MensagensListarUmaHandler::class, 
'api.mensagens.listar-uma' 


); 
Definindo a rota para criar um registro de mensagem 


Agora vamos definir a rota que sera responsavel por realizar a 
criação/inserção de registros de mensagens. Veja o código a seguir: 


$app->post( 
'/api/mensagens', 
App \Handler\Mensagens\MensagensCriarHandler::class, 
'api.mensagens.criar' 


3 


Definindo a rota para alterar os dados de um registro de 
mensagem 


Vamos definir agora como será o código de definição da rota 
responsável por realizar a alteracáo dos dados de um determinado 
registro de mensagem através do id que será informado como 
parámetro da URL. 


$app->put ( 
"/api/mensagens/{id}', 
App\Handler\Mensagens \MensagensAlterarHandler::class, 
'api.mensagens.alterar' 


)3 


Definindo a rota para deletar um registro de mensagem 


A última rota de mensagens que vamos definir é a responsável por 
excluir um registro de mensagem com base no id que será 
informado como parâmetro da URL. 


Veja a seguir o código dessa rota: 


$app->delete( 
'/api/mensagens/(id)', 
App\Handler\Mensagens \MensagensDeletarHandler::class, 
'api.mensagens.deletar' 


)5 


Finalizamos a definição das rotas de mensagens e de todas as rotas 
da aplicação. Como você pôde ver e já sabe bem, não mudou muita 
coisa. 


Agora podemos realizar os testes para verificarmos se tudo está 
funcionando corretamente. 


16.6 Testando as rotas de Mensagens 


Aqui estamos utilizando o Postman para realizar os testes, mas 
você poderá utilizar outra aplicação capaz de realizar as 
requisições. 


Testando a rota para criar um registro de mensagem 


Antes de prosseguirmos, devemos criar um novo registro de 
usuário, pois no último teste realizamos a exclusão do usuário. Esse 
passo você deverá fazer por meio da requisição de criar usuário. 
Depois siga para o passo descrito a seguir. 


Com o seu cliente de requisições aberto, informe na URL o 
endereço http://projeto-mezzio.local/api/mensagens . 


Altere o tipo de método HTTP para post e no corpo da requisição, 
informe o código JSON a seguir: 


"usuario": 2, 
"mensagem": "Ola, isso é uma mensagem de teste.", 
"ativo": true 


} 


No conjunto de dados a ser enviado para a requisição, o único ponto 
a ser levado em consideração, e que é extremamente importante, é 
a chave usuario. Essa chave deve possuir o id do registro de 
usuário existente; caso o valor inexistente seja informado, um erro 
ocorrerá, então atente-se a isso. 


Com tudo preparado e pronto para ser enviado, submeta a 
requisição. Se o resultado obtido for semelhante ao mostrado na 
imagem a seguir, significa que está tudo certo: 


POST + htipi/projeto-mezziolocal/api/fmensagens 


jody (6) 

Pretty | SON *¥ 3S 
1 H 
2 "data": { 
3 "id": 2, 
4 "mensagem": "Ola, isso é uma mensagem de teste.", 
5 "resposta": null, 
6 “data mensagem": { 
T "date": "2020-02-21 13:05:10.254496", 
3 “timezone type": 3, 
9 "timezone": "“America/Sao Paulo” 

18 Fe 

11 “is ativo": true, 

12 “criado em": { 

13 "date": "2020-02-21 13:05:10.247623", 
14 "timezone type": 3, 

15 "timezone": “America/Sao Paulo” 

16 F. 

17 "alterado_em": null, 

18 “deletado em": null, 

19 "usuario": { 

26 “ initializer": {}. 

21 > cloner_”: {}, 

22 " isInitialized ": false 

23 k 

24 k 

25 + 


Figura 16.11: Resposta da inserção de um registro de mensagem 


Perceba que na resposta que obtemos o campo resposta está null, 
isso porque quem responderá a mensagem será a nossa requisição 
de alteração de dados logo a seguir. 


Testando a rota para alterar os dados de um registro de 
mensagem 


Agora altere a URL no seu cliente de requisição para http://projeto- 
mezzio.local/api/mensagens/1 . Altere também o tipo da requisição para 
put e informe o JSON a seguir no corpo da requisição: 


{ 


"resposta": "Ola, sua mensagem foi respondida pelo teste.", 
"alteradoEm" : "2018-07-25 13:48:00" 


} 


Nesse caso, estamos respondendo a mensagem do usuario e 
informando a data de alteração do registro, então se você definiu 
tudo corretamente, você deverá ter uma saída semelhante à 
mostrada na imagem a seguir: 


PUT + | https/projeto-mezzio.localfapi/mensagens/1 


Jody (6) 
Pretty | JSON ~" => 
1 H 
2 "data": { 
3 "id": 1, 
4 "mensagem": "Ola, isso é uma mensagem de teste.", 
5 "resposta": "Ola, sua mensagem foi respondida pelo teste.”, 
6 "data mensagem": { 
T "date": "2020-02-21 13:04:14. 000000", 
B “timezone type": 3, 
g "timezone": "America'5ao Paulo” 
16 Te 
11 “is ativo": true, 
12 “criado em": { 
13 "date": "2020-02-21 13:04:14.000000", 
14 “timezone type": 3, 
15 "timezone”: "“America/Sa0 Paulo” 
16 te 
17 "alterado em": { 
18 "date": "2020-02-21 13:08:50.930437", 
19 “timezone type": 3, 
26 "timezone": “America/Sa0 Paulo” 
21 te — 
22 “deletado em": null, 
23 "usuario": { 
24 “initializer ": {}. 
25 "cloner *: {}. 
26 " isInitialized "“: false 
27 } 
28 k 
29 F 


Figura 16.12: Resposta da alteração dos dados da mensagem 


Perceba que dessa vez o campo resposta foi preenchido, ou seja, 
funcionou corretamente. 


Testando a rota para listar todos os registros de mensagens 


Vamos testar a rota que é responsável por realizar a listagem de 
todos os registros de mensagens inseridas no banco de dados. Para 
isso, informe a rota http://projeto-mezzio.local/api/mensagens €, em 
seguida, altere o tipo de requisição para cet e submeta a 
requisição. 


Se tudo ocorreu bem, você deverá ter uma saída semelhante à 
mostrada na imagem a seguir: 


GET +  http://projeto-mezzio.local/api/mensagens 


Pretty Raw li JSON v = 
1 4 
2 "data": ( 
3 “result with dql": [ 
4 { 
5 "id": 1, 
6 “mensagem": “Ola, isso é uma mensagem de teste.", 
7 "resposta": “Ola, sua mensagem foi respondida pelo teste.", 
8 “data mensagem": { 
9 "date": “2020-62-21 13:04:14.000000", 
10 “timezone type": 3, 
1 "timezone”: "America/Sao Paulo” 
12 de 
13 "is ativo": true, 
14 “criado em": { 
15 "date": "2020-02-21 13:04:14.000000", 
16 "timezone type": 3, 
17 "timezone": "America/Sao Paulo” 
18 }. 
19 “alterado em": { 
20 "date": "2020-02-21 13:08:50.000000", 
21 “timezone type": 3, 
22 "timezone": "America/Sao Paulo” 
23 Fo 
24 “deletado em”: null, 
25 "usuario": { 
26 "initializer": {}, 
27 "cloner “: TF, 
28 “ isInitialized ": false 
29 } 
30 y. 
31 { 
32 as 26 
33 “mensagem": “Ola, isso é uma mensagem de teste.", 


“4 Mer e E =..." 


Figura 16.13: Resposta da listagem de todas as mensagens 


Testando a rota para listar apenas um registro de mensagem 


Agora vamos testar a rota que retorna apenas uma mensagem com 
base no id que sera informado na URL. Altere a URL em seu 
cliente de requisição para http://projeto-mezzio.local/api/mensagens/1 , 
o tipo de requisição deve ser o mesmo, no caso o GeT. Em seguida, 
submeta a requisição e veja se o seu resultado é semelhante ao 
obtido na imagem a seguir: 


GET +  http://projeto-mezzio.local/api/mensagens/1 


Pretty JSON v 5 
1 q 
2 "data": { 
3 “result with dql": ( 
4 "id": 1, 
5 "mensagem": "Ola, isso é uma mensagem de teste.”, 
6 “resposta”: "Ola, sua mensagem foi respondida pelo teste.", 
7 “data mensagem": { 
8 “date”: "2020-02-21 13:04:14.000000", 
9 "timezone type": 3, 
10 "timezone": “America/Sao Paulo" 
11 >. 
12 “is ativo”: true, 
13 “criado em”: { 
14 “date”: "2020-02-21 13:04:14.000000", 
15 “timezone type": 3, 
16 "timezone": "America/Sao Paulo" 
17 k. 
18 “alterado em": { 
19 “date”: "2020-02-21 13:08:50.000000”, 
26 "timezone type": 3, 
21 "timezone": “America/Sao Paulo" 
22 k. 
23 “deletado em": null, 
24 "usuario": 4 
25 "initializer ": {}, 
26 " cloner ": O, 
27 " isInitialized ": false 
28 } 
29 k. 
30 "result without dql”: [ 
31 { 
32 e RR 
33 “mensanem": "Má. issn é uma mensanem de teste.". 


Figura 16.14: Resposta da listagem de apenas um registro de mensagem 
Testando a rota para deletar um registro de usuário 


Por fim, vamos testar a última rota de mensagens e a última rota da 
nossa aplicação. Essa rota é responsável por deletar um registro de 
mensagem do banco de dados. 


Para testá-la, informe a URL http://projeto- 
mezzio.local/api/mensagens/1 em seu cliente de requisição, altere o 
método da requisição para DELETE e, em seguida, submeta a 
requisição. Veja se o seu resultado obtido é semelhante ao 
mostrado na imagem a seguir: 


DELETE + hitpi/projeto-mezziolocal/api/fmensagens/ 
Pretty ON > 
1 | 
2 "data": { 
3 “message”: "Mensagem deletada com sucesso!” 
4 k 
5 È 


Figura 16.15: Resposta da exclusao de um registro de mensagem 


Finalizamos a definição e testes das rotas de mensagens. Com isso 
chegamos ao final do capítulo e, se você não teve nenhum 
problema até aqui, então você conseguiu concluir com sucesso a 
criação e a definição das rotas da aplicação. 


Caso você tenha tido algum problema devido a erros, tente revisar 
OS passos com calma e atenção, que tudo funcionará corretamente. 
Se mesmo assim algum erro for persistido, você poderá mandar 
uma mensagem em meu e-mail jhones.developer@gmail.com , que 
ficarei feliz em ajuda-lo. 


Um ponto importante a ser considerado: se você abrir o seu 
repositório MensagensRepository , Verá que nele existe um método 
chamado getmessagesFromUser . Esse método é responsável por obter 
todas as mensagens de um determinado usuário e ele não foi 
implementado de propósito. Então, como uma pequena lição, tente 


criar e registrar o Handler responsável por utilizá-lo. Crie também o 
método no serviço e, por fim, defina a rota para esse Handler e teste 
a sua aplicação. 


Conclusão 


Vimos neste capítulo como definir as rotas da aplicação e também 
como testá-las. Como você pôde ver, não foram códigos complexos 
e grandes. 


No momento de definir as suas rotas, atente-se ao Handler que 
você deverá chamar e também à rota. Tente criar rotas simples e 
intuitivas, pois rotas muito grandes acabam confundindo tanto o 
desenvolvedor que a criou, quanto desenvolvedores terceiros. 


Em nosso próximo capítulo, vamos falar rapidamente sobre as 
PSRs 7 e 15 com que o Mezzio é compatível. Siga em frente e 
vamos nessa! 


CAPITULO 17 
Conhecendo as PSRs 7 e 15 


Você sabe o que é PSR? Ja ouviu falar ou já teve contato? Caso 
não conheça, a PSR ou PHP Standard Recommendation (Padrão 
Recomendado para PHP, em português) são especificações que 
foram definidas pelos membros do PHP-FIG. Existem inúmeras 
PSRs, mas neste capítulo focaremos na PSR-7 e na PSR-15. 


O QUE É o PHP-FIG? 


É um grupo que tem foco em definir padrões de 
desenvolvimento para o PHP. Esses padrões vão desde o 


carregamento de classes, regras de formatação do código-fonte 
etc. Dentre os membros que fazem parte desse grupo temos: 
Zend Framework (Laminas), Symfony e Slim. 





É importante saber que o PHP-FIG define algumas palavras-chaves 
dentro das PSRs que servem como uma identificação no projeto, 
são elas: 


e MUST - DEVE 

e MUST NOT - NÃO DEVE 

e REQUIRED - OBRIGATÓRIO 

e SHALL - TEM QUE 

e SHALL NOT - NÃO TEM QUE 

e SHOULD - DEVERIA 

e SHOULD NOT - NÃO DEVERIA 

e RECOMMENDED - RECOMENDADO 
e MAY - PODE 

e OPTIONAL - OPCIONAL 


Agora que você já sabe, vamos conhecer a PSR-7 na seção a 
seguir. 


17.1 PSR-7 (HTTP Message Interfaces) 


O principal intuito dessa PSR é fornecer interfaces em comum para 
a troca de mensagens HTTP. Para que as aplicações possam se 
comunicar de maneira mais fácil, criou-se um padrão que é 
exatamente esse conjunto de interfaces definidas pela PSR-7 
juntamente com suas regras. Hoje muitos sistemas ainda se 
comunicam de maneiras diferentes e constantemente os 
desenvolvedores devem ficar estudando como uma determinada 
aplicação se comunica. Essa PSR visa tornar a nossa vida mais fácil 
também, então vamos conhecer suas regras. 


Mensagens 


Antes de prosseguirmos, você sabe o que é uma mensagem HTTP? 
Caso não saiba ou tenha dúvidas aqui vai uma breve explicação. 
Uma mensagem HTTP nada mais é do que uma requisição que uma 
aplicação faz para um servidor ou uma resposta de um servidor para 
a aplicação. 


Essa PSR define interfaces para as mensagens HTTP 
Psr\Http\Message\RequestInterface € PsriHttpiMessageiResponseInterface 
respectivamente. Ambas as interfaces estendem 
Psr\Http\Message\MessageInterface . Enquanto a interface 
Psr\Http\Message\MessageInterface PODE ser implementada 
diretamente, as classes concretas DEVEM implementar 
Psr\Http\Message\RequestInterface € PsriHttpiMessageiResponseInterface . 


Cabeçalhos HTTP 


O nome dos cabeçalhos devem ser case-insensitive, isto é, não 
deve fazer a distinção de letras maiúsculas e minúsculas, por 
exemplo, o cabeçalho authorization deve ser interpretado da 
mesma maneira que se fosse escrito authorization . Os cabeçalhos 
são recuperados através das classes que implementam a interface 


Psr\Http\Message\MessageInterface . Vamos analisar o exemplo a seguir 
que demonstra exatamente o funcionamento dessa regra: 


<?php 
namespace App\Middleware\Authorization 
use Psr\Http\Message\MessageInterface; 


class AuthorizationMiddleware 


{ 


private $mensagem; 


public function __construct(MessageInterface $mensagem) 


{ 


$this->mensagem = $mensagem; 


public function defineHeader() 


{ 


$mensagem = $this->mensagem->withHeader('authorization', 
"Bearer AbcDef1234@#' ); 


echo $mensagem->getHeaderLine( ‘authorization’ ); 
// Vai retornar: AbcDef1234@# 


echo $mensagem->getHeaderLine(' AUTHORIZATION'); 
// Vai retornar: AbcDef1234@# 


$mensagem = $this->mensagem->withHeader('Authorization', 
'1234567890abcdef! (0% '); 

echo $mensagem->getHeaderLine('authorization'); 

// Vai retornar: 1234567890abcdef ! @$ 


} 


Como podemos ver no exemplo anterior, apesar de os cabeçalhos 
serem recuperados independentemente do tipo da escrita, sem 
diferenciar letras maiúsculas e minúsculas, o nome original DEVE 


ser mantido pela aplicação quando for recuperado por meio do 
método getHeaders() . 


Os cabeçalhos também podem possuir múltiplos valores que podem 
ser definidos e recuperados de maneira simples e sem dor de 
cabeça. Isso se dá por meio de uma instância de 
Psr\Http\Message\MessageInterface Que NOS disponibiliza dois métodos, 
sendo eles: getHeaderLine() @ getHeader() , sendo que O método 
getHeaderLine() retorna os valores contidos dentro do cabeçalho em 
formato de string, já o método getHeader() retorna os valores 
contidos no cabeçalho em forma de array . Para simplificar o 
entendimento, vamos analisar o exemplo a seguir que demonstra o 
funcionamento na prática: 


<?php 
namespace App\Middleware\Authorization 
use Psr\Http\Message\MessageInterface; 


class AuthorizationMiddleware 


{ 


private $mensagem; 


public function __construct(MessageInterface $mensagem) 


{ 


$this->mensagem = $mensagem; 


public function defineHeaderValues() 


{ 


$mensagem = $this->mensagem->withHeader('authorization', 
"Bearer AbcDef1234@#' ) 
->withAddedHeader('authorization', 'Bearer 1234567890') 


$cabecalhoString = $mensagem->getHeaderLine('authoriation'); 
//Retorna ‘Bearer AbcDef1234@#, Bearer 1234567890' 


$cabecalho = $mensagem->getHeader( ‘authorization’ ); 


//Retorna ['Bearer AbcDef1234@#', ‘Bearer 1234567890'] 


} 


Conforme podemos ver, definimos dois valores para um mesmo 
cabeçalho e os recuperamos de duas formas diferentes, em forma 
de array e em forma de string . Uma observação muito importante 
a ser considerada é que nem todos os valores podem ser 
concatenados usando uma vírgula (por exemplo, set-Cookie ). 
Quando for trabalhar com esses cabeçalhos, a aplicação DEVE 
confiar no método getHeader() que está contido na interface 
Psr\Http\Message\MessageInterface para obter esses cabeçalhos com 
múltiplos valores. 


Em requisições, o cabeçalho do host espelha o componente de host 
do URI (Uniform Resource Identifier ou Identificador de Recursos 
Universal, em português), assim como o host utilizado ao 
estabelecer a conexão TCP (Transmission Control Protocol ou 
Protocolo de Controle de Transmissão). No entanto, a especificação 
do HTTP permite que o cabeçalho de host seja diferente de cada 
um dos dois. As aplicações DEVEM tentar definir o cabeçalho de 
host de um URI se nenhum cabeçalho dele for definido. Por padrão, 
o método withuri() definido na interface 
Psr\Http\Message\RequestInterface substituira o pedido retornado com 
um cabeçalho de host correspondente ao componente do host 
passado. 


Você poderá optar por preservar o estado original do cabeçalho do 
host passando true para o segundo parâmetro do método 
withuri() . Quando esse parâmetro é definido como true , o pedido 
retornado não atualizará o cabeçalho do host retornado pela 
mensagem, a menos que ela não possua nenhum cabeçalho de 
host definido. 


Streams (Fluxos) 


As mensagens HTTP consistem em uma linha inicial (método), 
cabeçalhos e um corpo, sendo que o corpo de uma mensagem 
HTTP pode possuir tamanhos variados desde muito pequeno a 
extremamente grande. Ao tentar representar o corpo de uma 
mensagem como uma string, por exemplo, a aplicação facilmente 
consome mais memoria do que o necessário. Isso ocorre porque o 
corpo dessa mensagem deve ser armazenado completamente na 
memoria. A tentativa de armazenar o corpo de uma requisição ou 
resposta na memória impediria que o uso dessa solução fosse 
possível, pois trabalhar com esse tipo de implementação afetaria a 
performance da aplicação quando fôssemos trabalhar com grandes 
corpos de mensagens. 


A interface Psr\Http\Message\StreamInterface é utilizada para ocultar os 
detalhes da implementação quando um determinado fluxo de dados 
é lido ou escrito. Além disso, essa interface expõe diversos métodos 
que permitem que os fluxos sejam lidos, escritos e percorridos de 
forma eficaz. Os streams (fluxos) expõem seus recursos utilizando 3 
métodos: isReadable() , isWritable() € isSeekable() , Cada um pode 
ser utilizado para determinar se um fluxo de dados é capaz de 
atender a seus requisitos ou não. 


Cada instância do stream (fluxo de dados) terá diversos recursos, 
como somente para leitura, somente para gravação ou para 
leitura/gravação. Também pode permitir acesso aleatório ou apenas 
acesso sequencial, como um fluxo de dados baseado em socket 
(soquete). Por fim, a interface psriHttpiMessageistreamInterface define 
um método _ tostring() para simplificar, recuperar ou emitir todo o 
conteúdo do corpo da mensagem de uma única vez. 


Ao contrário das interfaces de requisicáo 
Psr\Http\Message\RequestInterface € resposta 
Psr\Http\Message\ResponseInterface , a interface 
Psr\Http\Message\StreamInterface não é um modelo de imutabilidade, 
ou seja, em casos em que um fluxo real do PHP é empacotado, a 
imutabilidade é impossível de ser aplicada, bem como em qualquer 


código que interage com o recurso, podendo alterar seu estado 
(incluindo posição do cursor, conteúdo etc.). 


É recomendado que as aplicações utilizem fluxos somente leitura 
para requisições efetuadas do lado do servidor e respostas do lado 
do cliente. Além disso, as aplicações consumidoras DEVEM estar 
cientes de que a instância Psr\Http\Message\StreamInterface PODE ser 
mutável podendo alterar o estado da mensagem. 


Solicitar destinos e URIs 


As mensagens de solicitação contêm um pedido-alvo como segundo 
segmento da linha de solicitação, sendo que o destino pode ser 
alguma das seguintes formas: 


e origin-form - Se presente na string de consulta, é chamado de 
URL (Uniform Resource Locator, ou Localizador Padrão de 
Recursos, em português) relativo. Geralmente, as mensagens 
transmitidas por TCP são de origem e os dados de esquema e 
autoridade geralmente só estão presentes por meio de variáveis 
CGI (Common Gateway Interface). 

e absolute-form - Consiste no esquema, autoridade ( [user- 
info@]host[:port] , onde os itens entre colchetes são opcionais), 
caminho (se presente), string de consulta (se presente) e 
fragmento (se presente). Isso geralmente é chamado de URI 
absoluto e é a única forma para especificar um URI. Essa forma 
é usada ao fazer solicitações para Proxies HTTP, por exemplo, 
em um ambiente corporativo em que existe proxy configurado, 
restringindo o acesso. 

e authority-form - Consiste apenas na autoridade, é normalmente 
usado apenas em solicitações connect para estabelecer uma 
conexão entre um cliente HTTP e um servidor de proxy. 

e asterisk-form - Consiste unicamente na string * e é utilizado 
com o método options para determinar as capacidades gerais 
de um determinado servidor da Web. 


Além desses pedidos-alvo, ou metas de solicitação, ha algumas 
vezes em que um URL efetivo pode ser encontrado separado da 
segmentação da solicitação. Esse URL efetivo não é transmitido em 
uma mensagem HTTP, mas é utilizado para determinar o tipo de 
protocolo que será utilizado ( http/https ), a porta e o nome do host 
para fazer a requisição. 


O URI efetivo é representado pela interface 
Psr\Http\Message\UriInterface , que disponibiliza métodos para 
interagir com diversas partes do URI, o que eliminará a necessidade 
de análise repetitiva. Além disso, especifica um método _ tostring() 
para que seja possível converter o objeto URI em uma 
representação em formato de string. 


Ao recuperar o pedido-alvo com o método getRequestTarget() , por 
padrão, o método utilizará o objeto URI e extrairá todos os 
componentes necessários para construir o formulário de origem - 
este é o pedido-alvo mais comum. Caso seja necessário que um 
usuário final utilize uma das outras formas, ou se o usuário desejar 
substituir o destino da solicitação, é possível fazer essa alteração 
utilizando o método withRequestTarget() . À chamada desse método 
não vai afetar o URI, pois ele é retornado através do método 
geturi(). 


Vamos analisar um exemplo em que o usuário efetua uma 
solicitacáo usando o formulário de asterisco para um determinado 
servidor: 


<?php 

namespace App\Middleware\Authorization 
use Psr\Http\Message\RequestInterface; 
class AuthorizationMiddleware 


{ 


private $request; 


public function _ construct(RequestInterface $request) 


{ 
$this->request = $request->withMethod( 'OPTIONS' ) 
->withRequestTarget('*') 
->withUri(new Uri('https://www.php-fig.org/')); 
} 


} 


O resultado obtido dessa alteração seria semelhante ao mostrado a 
seguir: 


OPTIONS * HTTP/1.1 


Caso necessário, o cliente HTTP pode utilizar o URL efetivo obtido 
através do método geturi() para definir o protocolo, o hostname e a 
porta a ser utilizada. O cliente HTTP DEVE ignorar os valores 
contidos nos métodos getPath() € getQuery() presentes na interface 
Psr\Http\Message\UriInterface € utilizar o valor obtido através do 
método getRequestTarget() , que por padrão concatena os valores 
obtidos nos métodos anteriormente citados ( getPath() € getQuery() ). 


Os clientes que optarem por não fazer a implementação de uma ou 
mais das 4 formas de pedido-alvo, deveráo, mesmo assim, utilizar o 
método getRequestTarget() . Esses clientes devem rejeitar as metas 
de solicitação porque eles não suportam e NÃO DEVEM retroceder 
nos valores obtidos através do método geturi() . 


A interface Psr\Http\Message\RequestInterface disponibiliza métodos 
para recuperar o destino da solicitação ou criando uma nova 
instância com o destino fornecido. Por padrão, caso o destino da 
solicitação não seja especificamente composto, então o método 
getRequestTarget() retornará o formulário de origem do URI 
composto, ou / se nenhum URI for composto. 


O método withRequestTarget ($requestTarget) é responsável por criar 
uma nova instância com a solicitação de destino especificada, 
permitindo que os desenvolvedores criem mensagens de solicitação 
que possam representar as outras três formas de solicitação de 
destino (formulário absoluto, formulário de autoridade e formato 


asterisco). Quando utilizada, a instancia de URI composta ainda 
pode ser utilizada, principalmente em clientes que requerem a 
criação da conexão com o servidor. 


Requisições do lado do servidor 


A interface Psr\Http\Message\RequestInterface fornece uma 
representação geral de uma solicitação de uma mensagem HTTP, 
porém essas solicitações precisam de um tratamento adicional do 
lado do servidor. O processamento do lado do servidor precisa levar 
em consideração a CGl e ainda a abstração do PHP por meio da 
extensão de CGI. O PHP fornece uma simplificação em torno do 
empacotamento de entrada por meio de variáveis superglobais, 
como: 


e $ cooKIE - Desserializa e concede acesso simplificado aos 
cookies HTTP. 

e $ GET - Desserializa e concede acesso simplificado aos 
parámetros da string de consulta. 

e $ post - Desserializa e concede acesso simplificado aos 
parámetros enviados via método post do HTTP. 

e $ FILES - Provê metadados que são serializados ao fazer 
uploads de arquivos. 

e $ SERVER - Concede acesso a variáveis de ambiente CGI/SAPI, 
que incluem o método de solicitação, o esquema de solicitação, 
o URI de solicitagao e os cabecalhos. 


A interface Psr\Http\Message\ServerRequestiInterface estende a interface 
Psr\Http\Message\RequestInterface para que seja possível obter uma 
abstração envolvendo essas variáveis superglobais, ajudando a 
reduzir o acoplamento junto a essas variáveis pelos clientes. Além 
disso, incentiva e promove a capacidade de testar a solicitação dos 
clientes. A solicitação do servidor fornece uma propriedade adicional 
chamada attributes para permitir aos clientes a capacidade de 
introspecção, decomposição e combinação da solicitação contra 
regras específicas da aplicação como: caminho, esquema, host etc. 


A solicitagao do servidor também pode fornecer mensagens entre 
varios pedidos. 


Upload de arquivos - A interface 
Psr\Http\Message\ServerRequestinterface especifica um método para 
recuperar uma árvore de arquivos decorrentes de uploads em uma 
estrutura onde cada folha é uma instância de 
Psr\Http\Message\UploadFileInterface . E importante ressaltar que a 
variável superglobal $ FILES possui alguns problemas ao lidar com 
arrays de entradas de arquivos, por exemplo, se a aplicação enviar 
um array de arquivos contendo uma chave chamada arquivos e 
submetendo $arquivos[@] € $arquivos[1] , teremos a seguinte saída 
dada pelo PHP. 


array( 
'arquivos' => array( 
‘name’ => array( 
© => 'file0.txt', 
1 => 'filel.html', 
), 
‘type’ => array( 
@ => ‘text/plain’, 
1 => 'text/html', 
), 
/* etc. */ 
), 
) 


Quando, na verdade, o esperado seria algo como: 


array ( 
'arquivos' => array( 

9 => array( 
'name' => 'file0.txt', 
'type' => 'text/plain', 
METE 

)s 

1 => array( 
'name' => 'filel.html', 
'“type' => 'text/html', 


Pres 
)s 
)s 
) 


Os desenvolvedores precisam conhecer o detalhe dessa 
implementação da linguagem PHP e assim escrever um código que 
possa reunir os dados de um upload em específico. Além disso, há 
cenários em que $ FILES Não é preenchido: 


e Quando o método HTTP não é post; 
e Quando estiver utilizando teste de unidade; 
e Quando o ambiente não for SAPI. 


Nesses casos, os dados terão que ser distribuídos de maneira 
diferente, por exemplo: 


e Um processo pode tentar analisar o corpo da mensagem para 
descobrir os uploads de arquivos. Em alguns casos, a aplicação 
pode não gravar os uploads de arquivos no sistema de 
arquivos, mas podem colocá-los num fluxo para reduzir o uso 
da memória, E/S (Entrada e Saída) e armazenamento. 

e Durante os testes de unidade, os desenvolvedores precisam 
simular os metadados de upload de arquivo para validar e 
verificar diferentes cenários. 


O método getuploadedFiles() fornece uma estrutura padronizada 
para a aplicação, sendo que é esperado que: 


e Todas as informações para um determinado upload de arquivo 
sejam agregadas e usadas para popular a instância de 
Psr\Http\Message\UploadedFileInterface . 

e Recriar a estrutura da árvore, sendo que cada folha é uma 
instância de Psr\Http\Message\UploadedFileInterface Para um local 
determinado na arvore. 


A estrutura da arvore referenciada deve imitar a estrutura de 
nomenclatura na qual os arquivos foram submetidos. Veja o 


exemplo a seguir que demonstra a estrutura utilizando $ FILES: 


array( 
“php field" => array( 
“tmp name" => "phpUelOru', 
'name' => 'php-logo.png', 
'size' => 10586, 
'type' => 'image/png', 
'error' => 0, 
)s 
) 


Agora veja como ficaria utilizando o método getuploadedFiles() : 


array( 
“php field' => //Instancia de UploadFileInterface 


)s 
) 


Em alguns casos, vocé pode definir um array de arquivos, mas 
nesse caso a implementação da especificação deve agregar todas 
as informações relacionadas ao arquivo de acordo com o índice 
fornecido, isso porque ¢ FILES acaba saindo da sua estrutura 
convencional em alguns casos. Como os dados dos arquivos 
enviados são derivados de $ FILES OU do corpo do pedido, o 
método withUploadedFiles() também está disponível na interface 
Psr\Http\Message\UploadedFileInterface , permitindo a delegação da 
padronização para um outro processo. Além disso, a interface 
disponibiliza métodos que garantem que as operações funcionarão 
independentemente do ambiente: 


e O método moveTo($targetPath) é disponibilizado como uma 
alternativa recomendada e segura para realizar chamadas 
através do método move uploaded file() diretamente no arquivo 
temporário. As implementações vão detectar a operação correta 
para ser utilizada conforme o ambiente. 

e O método getstream() retornará uma instância de 
Psr\Http\Message\StreamInterface . Em ambientes que não sejam 
SAPI, a proposta é realizar uma análise dos arquivos de upload 


individuais em php://temp . Em alguns casos, o arquivo de 
upload não está presente, portanto, o método getstream() é 
garantido para manter a funcionalidade independentemente do 
ambiente. 


Após termos passado por toda a PSR-7, não podíamos deixar de 
especificar as interfaces que fazem parte desse pacote, então 
vamos conferi-las a seguir: 


Psr\Http\Message\MessageInterface 


<?php 
namespace Psr\Http\Message; 


interface MessageInterface 
{ 
public function getProtocolVersion(); 
public function withProtocolVersion($version); 
public function getHeaders(); 
public function hasHeader ($name); 
public function getHeader ($name); 
public function getHeaderLine($name); 
public function withHeader($name, $value); 
public function withAddedHeader ($name, $value); 
public function withoutHeader ($name); 
public function getBody(); 
public function withBody(StreamInterface $body) ; 
} 


Psr\Http\Message\RequestInterface 


<?php 
namespace Psr\Http\Message; 


interface RequestInterface extends MessageInterface 

{ 
public function getRequestTarget(); 
public function withRequestTarget($requestTarget); 
public function getMethod(); 


public function withMethod($method) ; 
public function getUri(); 


public function withUri(Urilnterface $uri, $preserveHost = false); 


} 


Psr\Http\Message\ServerRequestinterface 


<?php 


namespace Psr\Http\Message; 


interface ServerRequestInterface extends 


{ 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 

} 


function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 


RequestInterface 


getServerParams(); 

getCookieParams(); 

withCookieParams (array $cookies); 
getQueryParams(); 

withQueryParams(array $query) ; 
getUploadedFiles(); 
withUploadedFiles(array $uploadedFiles) ; 
getParsedBody(); 
withParsedBody($data) ; 
getAttributes(); 
getAttribute($name, $default = 
withAttribute($name, $value); 
withoutAttribute($name) ; 


null); 


Psr\Http\Message\ResponseInterface 


<?php 


namespace Psr\Http\Message; 


interface ResponseInterface extends MessageInterface 


{ 


public function getStatusCode(); 
public function withStatus($code, $reasonPhrase = ''); 
public function getReasonPhrase(); 


} 


Psr\Http\Message\StreamInterface 


<?php 


namespace Psr\Http\Message; 


interface StreamInterface 


{ 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 

} 


function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 
function 


__toString(); 

close(); 

detach(); 

getSize(); 

tell(); 

eof (); 

isSeekable(); 
seek(foffset, fwhence = 
rewind(); 

isWritable(); 
write($string); 
isReadable(); 
read($length) ; 
getContents(); 
getMetadata($key = null); 


Psr\Http\Message\UriInterface 


<?php 


namespace Psr\Http\Message; 


interface Urilnterface 


{ 
public 
public 
public 
public 
public 
public 
public 
public 
public 
public 


function 
function 
function 
function 
function 
function 
function 
function 
function 
function 


getScheme() ; 

getAuthority(); 
getUserInfo(); 

getHost(); 

getPort(); 

getPath(); 

getQuery(); 

getFragment(); 
withScheme($scheme) ; 
withUserInfo($user, $password 


SEEK SET); 


null); 


public function withHost($host) ; 

public function withPort($port) ; 

public function withPath($path) ; 

public function withQuery ($query) ; 
public function withFragment ($fragment); 
public function _ toString(); 


} 


Psr\Http\Message\UploadedFileInterface 


<?php 
namespace Psr\Http\Message; 


interface UploadedFileInterface 


{ 
public function getStream(); 
public function moveTo($targetPath); 
public function getSize(); 
public function getError(); 
public function getClientFilename(); 
public function getClientMediaType(); 


} 


Com isso, nós chegamos ao final da PSR-7, que define interfaces 
em comum para que a troca de mensagens HTTP se torne mais 
simples. Não é uma regra tao simples de ser seguida e é preciso ter 
muita atenção no momento em que estiver implementando a PSR-7 
em sua aplicação. São muitos detalhes que devem ser seguidos 
para que o seu código possa estar em conformidade com essa PSR. 
O que foi descrito aqui pode ser visto com mais detalhes no link 
https://www.php-fig.org/psr/psr-7/. 


Na próxima secáo vamos conhecer a PSR-15. 


17.2 PSR-15 (HTTP Server Request Handlers) 


Com o principal objetivo de fornecer interfaces comuns para a 
manipulação das solicitações HTTP, OS Handlers (manipuladores) sao 
essenciais em qualquer aplicação Web. O código do lado do 
servidor recebe uma solicitação, que é processada, e então é 
gerada uma resposta que pode ser repassada para outra aplicação 
ou não. 


Os Handlers em APIs podem ser considerados como estruturas que 
trabalham sobre o protocolo HTTP, sendo que recebem uma 
requisição/solicitação de entrada e geram uma resposta como 
saída, que pode ou não ser repassada para outros Handlers. Por 
exemplo, para realizar a autenticação de um usuário, teríamos algo 
como um Handler de autenticação que recebe as credenciais do 
usuário. Se os dados estiverem corretos, então ele poderá passar 
para o próximo Handler, indicando que a autenticação foi bem- 
sucedida e está pronta para receber autorização para acessar os 
recursos permitidos para aquele usuário. 


Para entendermos melhor o funcionamento dos Handlers, veja o 
exemplo a seguir que demonstra o seu funcionamento dentro de 
uma API: 


AuthenticationMiddleware 









Request 
(Solicitação/Requisição) 





Figura 17.1: Funcionamento Middlewares 


Conforme mostrado na imagem anterior, nós temos duas camadas 
de Middlewares/Handlers. O authenticationMiddleware recebe a 
requisição. Após receber a requisição é realizada uma verificação 
que pode ou não conceder o acesso ao usuário. Em caso afirmativo, 
os dados da solicitação são passados para o próximo 
Middleware/Handler, que no caso do exemplo é o 
AuthorizationMiddleware . 


O authorizationMiddleware é responsável por verificar se o usuário 
possui autorização para acessar um determinado recurso do 
sistema, se sim, então os dados são enviados para a camada da 
aplicação para continuar o processamento. Podemos ter quantos 
Middlewares/Handlers forem necessários, tudo vai depender da sua 
aplicação. 


Vamos conhecer a seguir as regras que definem essa PSR para 
entendermos como aplicá-la de forma coesa. 


Request Handlers (Manipuladores de Requisição/Solicitação) 


É um componente individual que realiza o processamento de uma 
solicitação e consequentemente gera uma resposta, conforme 
definida pela PSR-7. Um Request Handler PODE lançar uma exceção 
caso as condições da solicitação/requisição forem impedidas de 
produzirem uma resposta, porém, o tipo de exceção não está 
definido. Os Requests Handlers que utilizam esse padrão DEVEM 
implementar a interface PsriHttpiServeriRequestHandlerInterface . 


Middleware 


É um componente individual que trabalha junto com outros 
Middlewares/Handlers durante o processamento de uma 
requisição/solicitação e gera uma resposta como saída, conforme 
definida pela PSR-7. Um Middleware/Handler PODE criar e retornar 
uma resposta sem que haja a delegação para um Request Handler 
desde que as condições necessárias sejam atendidas. Para utilizar 
este padrão, os middlewares DEVEM implementar a interface 
Psr\Http\Server\MiddlewareInterface . 


Generating Responses (Gerando Respostas) 


E RECOMENDADO que qualquer manipulador 
(Handler/Middleware) ou de solicitação/requisição (Request) que 
gere uma resposta componha um modelo de resposta baseado na 
PSR-7, implementando a interface Psr\Http\Message\ResponseInterface 
ou até mesmo uma Factory (fabrica) capaz de gerar uma instancia 
de Psr\Http\Message\ResponselInterface . Assim evita-se dependéncia de 
uma implementação específica de mensagem HTTP. 


Handling Exceptions (Tratamento de Exceções) 


É RECOMENDADO que qualquer aplicação que utilizar o 
Middleware/Handler inclua um componente responsável por realizar 
a captura das exceções e as converta em respostas. Este 
Middleware DEVE ser o primeiro componente a ser executado e 
envolver todo o processamento adicional para garantir que uma 
resposta seja sempre gerada. 


Essas são as regras que a PSR-15 define, não é nada complicado e 
é tecnicamente muito simples de implementar em sua aplicação. A 
maioria dos frameworks e microframeworks já possui suporte a essa 
PSR. Basta você desenvolver a lógica da sua aplicação e seguir as 
regras conforme estipuladas. 


A seguir, vamos conhecer as interfaces que fazem parte desse 
pacote, são elas: 


Psr\Http\Server\RequestHandlerInterface - Essa interface DEVE ser 
implementada por componentes de Middleware/Handler 
compatíveis. 


<?php 
namespace Psr\Http\Server; 


use Psr\Http\Message\ResponselInterface; 
use Psr\Http\Message\ServerRequestInterface; 


interface RequestHandlerInterface 


{ 

public function handle(ServerRequestInterface $request): 
ResponseInterface; 
} 


Psr\Http\Server\MiddlewareInterface - Essa interface DEVE ser 
implementada pelo componente de Middleware/Handler compatível. 


<?php 
namespace Psr\Http\Server; 


use Psr\Http\Message\ResponseInterface; 
use Psr\Http\Message\ServerRequestInterface; 


interface MiddlewareInterface 


{ 


public function process(ServerRequestInterface $request, 


RequestHandlerInterface $handler): ResponseInterface; 


} 


Conforme você pôde ver, são duas interfaces bem simples que não 
possuem muitos métodos, mas definem perfeitamente os conceitos 
de Middlewares/Handlers e manipuladores de solicitação/requisição 
para que sua aplicação possa ou não delegar os dados para um 
outro Middleware/Handler. 


Conclusão 


Vimos aqui os conceitos, regras e aplicações das PSRs 7 e 15 que 
visam padronizar como tratamos nossas requisições e como delegar 
a requisição para outros Handlers até que um Handler possa ser 
capaz de realizar o tratamento adequado. 


Tudo isso é feito por meio do conjunto de interfaces que fazem parte 
de cada um dos pacotes. Cada interface disponibiliza métodos que 
tratam de uma determinada tarefa. 


Essas PSRs são muito utilizadas em sistemas Web com o PHP e 
não poderiam ficar de fora deste livro. E importante conhecê-las, já 
que elas facilitam e muito a vida dos desenvolvedores. 


CAPITULO 18 
Conclusao 


E isso ai meu amigo, chegamos ao final do livro e espero que vocé 
tenha gostado do que vimos durante todos esses capitulos. 


O intuito desta obra foi demonstrar como podemos desenvolver uma 
aplicação REST com o Mezzio, que é um poderoso microframework. 
Junto a isso, realizamos a integração dele com o ORM Doctrine 
para trabalharmos na camada de abstração de dados proveniente 
do banco de dados. 


Como você pôde ver, as coisas no Mezzio devem ser bem 
explicitadas, ou seja, criou um Handler? Registre esse Handler. 
Criou um serviço? Então, registre esse serviço. Durante todos esses 
capítulos, vimos desde os conceitos de API, frameworks, 
microframeworks até aos conceitos das PSRs 7 e 15. 


Geramos entidades automaticamente utilizando o Doctrine, criamos 
os repositórios dessas entidades, criamos diversos Handlers, 
Factories, serviços, definimos as rotas da nossa aplicação e muito 
mais. 


Vale ressaltar que muitas melhorias podem ser feitas no código, 
como a criação de Handlers para filtrarem e validarem os dados 
enviados pela aplicação cliente, dentre outras. 


Nesta obra, foram demonstrados apenas os conceitos para 
desenvolver com o Mezzio e, como você pôde ver, não é difícil, mas 
sim, trabalhoso. Se você já estiver habituado com o Zend 
Framework (Laminas), então você não verá muita diferença no 
trabalho. Mas se você estiver vindo de um framework como o 
Laravel, então verá que as coisas por aqui realmente são mais 
trabalhosas, mas nada que uma questão de costume e adaptação 
não resolva :). 


Caso vocé tenha tido duvidas, criticas, sugest6es vocé podera 
entrar em contato em um dos canais: 


e E-mail: jhones.developer@gmail.com 
e LinkedIn: https://www.linkedin.com/in/jhones-dos-santos- 
clementino-91a90256/ 


Ficarei muito feliz em lhe responder e trocar conhecimentos. 


Abraços e até a próxima! 
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